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.
At the moment I'm trying to rewrite grive , because its maintainer
did not migrate it to the new Google APIs.
After reviewing the code, I decided, that maybe using the google api cpp
client libraries would be a good choice since the original author of
grive did implement similar things as the official google API does.
So I created packages for those APIs in the AUR. Everything fine so far.
The problem is, google is using an old version (3.7) of the simple
embedded webserver mongoose as backend in its current stable
release. I tried using the current version of mongoose, but the
developers have some functions removed that google uses. So I'm stuck
with using version 3.7 .
Since however cmake won't build shared libraries (even with
-DBUILD_SHARED=ON) of google-api-cpp-client, mongoose is already
statically linked into the libgoogleapis_mongoose.a . The only problem
is that one header of googleapis (mongoose_webserver.h) has the line
"#include <mongoose/mongoose.h>". No problem for compilation, but when
using the headers in an own project, there won't be any file at this place.
The mongoose 5 package in AUR installs its header to
So I'm stuck with the question wether
- to create a new package "mongoose3" for the header only since nothing
more is needed (more dependencies) and hope for google fixing that issue
with the next more current release
- just include the mongoose header in "/usr/include/mongoose3.h", patch
the include in google webserver to use that file and include the license
of mongoose version 3 in my google-api-cpp-client package.
Personally, I'd prefer the second conclusion since AFAIK no other
package needs this header and google is working on its web section on
the master branch, so it probably won't be needed anymore in near
future. But I'm not sure, so it would be nice to have your opinion on that.