I am the current maintainer of the AUR package
ttf-google-webfonts-hg, and I'm bothered by the mess of various
packages there are for Google's Web Fonts project. It's not at all
KISS in its current state.
There are currently four different AUR packages that
essentially supply the same files, and all four packages conflict with
each other. Around August of 2012, the package named
ttf-google-webfonts was orphaned, and user w0ng created a GitHub
repository that mirrors the Mercurial repository on Google Code
(why?). Then, the new maintainer changed the original
ttf-google-webfonts package from a VCS-type package that simply lacked
"-hg" in the name to a package that pulls tarballs from w0ng's GitHub
As you can see in the comments for ttf-google-webfonts, this has
caused all sorts of confusion and messages about the package being
out-of-date or having invalid checksums. To get around these issues,
user epinephrine created the package ttf-google-webfonts-git that
clones w0ng's GitHub repo instead of pulling tarballs from it,
which significantly reduces the maintenance required on the package.
Then, user Gently created a package named
ttf-google-webfonts-distilled that pulls a tarball from w0ng's
GitHub repo and only installs a small subset of the fonts therein.
Shortly after ttf-google-webfonts was changed from being a
Mercurial-based package and not liking the direction that the package
was taking, I reuploaded the original ttf-google-webfonts package as
ttf-google-webfonts-hg for people that simply wanted the old
package back that uses the actual Google Web Fonts repository to
download the files.
To clean up this mess, I propose that ttf-google-webfonts-distilled
and ttf-google-webfonts-git be deleted outright, for what should be
obvious reasons. I also propose that ttf-google-webfonts be deleted
because of how frequently the Web Fonts project is updated and because
the project lacks version numbers. If people really feel strongly
about keeping that maintenance nightmare, then let them have it, but I
really don't see what advantage it provides over the original
ttf-google-webfonts-hg other than one less makedepends.
I apologize for the huge email, but this situation really is a mess.
On Tue, Feb 24, 2015 at 11:35 PM, Christopher Reimer <mail(a)creimer.net> wrote:
> Hi list,
> I'm maintainer of a project called VDR4Arch.
> I recently started taking over a bunch of packages in AUR. My main goal is
> to follow the best practices from the Developer Wiki as good as possible.
> A lot of plugins for vdr are more or less orphaned upstream. There are no
> regular releases and the last one is usually a year back. However there are
> still commit in the GIt repository. And around the vdr community it's common
> practice to use these Git revisions and consider them stable. The community
> even keeps these plugins alive with compatibility patches.
> Usually I would say that these are VCS packages and need to be suffixed by
> -git. But to distribute the version everyone in the community expects I
> started using the VCS feature with fixed commit ids, which are tested by me
> or somebody trusted. I create these packages without the -git suffix.
> I'd like to know how a Trusted User or even an Arch Developer would handle
> this. Is this approach acceptable?
-git packages are expected to track the latest development (usually
the master branch), generating a dynamically versioned package from
the head commit. If you lock your releases to certain commits or tags,
it's not fundamentally different from a package using tarballs.
If you grep ABS for '#\(tag\|commit\|revision\)=' you'll find a lot of
packages grabbing sources from bzr, git or svn.
I'm maintainer of the vdr package in AUR.
All vdr plugin packages depend on vdr-api with a fixed version. As you
can see right now the version of vdr-api and vdr itself are the same.
Since version 2.0.0 it's common practice to bump the plugin version to
e.g. 2.0.1 but keep the plugin API version at 2.0.0.
Which means plugins don't have to be rebuild and therefore no pkgrel
bump is necessary. AUR Web doesn't detect the dependency between the vdr
package which provides vdr-api and a plugin which depends on vdr-api.
At a later version, I think it was 2.0.3 the API version was bumped,
too. So just checking on major and first minor version as it's done with
the kernel package doesn't work here.
I conclude from this that I did something wrong and I should handle this
different. But I don't really know how.
I'm maintainer of a project called VDR4Arch.
I recently started taking over a bunch of packages in AUR. My main goal
is to follow the best practices from the Developer Wiki as good as
A lot of plugins for vdr are more or less orphaned upstream. There are
no regular releases and the last one is usually a year back. However
there are still commit in the GIt repository. And around the vdr
community it's common practice to use these Git revisions and consider
them stable. The community even keeps these plugins alive with
Usually I would say that these are VCS packages and need to be suffixed
by -git. But to distribute the version everyone in the community expects
I started using the VCS feature with fixed commit ids, which are tested
by me or somebody trusted. I create these packages without the -git suffix.
I'd like to know how a Trusted User or even an Arch Developer would
handle this. Is this approach acceptable?