eglibc doesn’t believe in releases
by Mark Miller
I was looking at the eglibc source to see about adding it as an option to the C libraries Firmware Linux has. Right now, it only supports uClibc/uClibc++. However, apparently they don’t believe in releases.
A quote from one of the developers:
EGLIBC sources are for system integrators, who need a wide range of expertise and are considered unlikely to be behind restrictive network connections for which checking out release branches is a problem, or to have a use for a tarball with known bugs that are fixed later on the release branch.
That’s just mind-boggling. Not having an actual release tarball so one can point to and go, “Here, I’m on version 2.3.10, this worked for me”, and instead claiming that a source code repository is perfectly fine as a release standpoint, is insane. The justification that I wouldn’t want to have a stable tarball when there might be patches later in the release branch is also idiotic. That’s what maintenance releases are for. Okay, so 2.3.10 had a bug, release 2.3.11! Or 2.3.10.1! Whichever! Having releases also allows one to regression test sanely as well.
When a project relies on its source code repository for a release, that means that if I grab an svn checkout, and I need to package it up for whichever build system or distribution technique I’m using, I’d better hope that I record the svn commit in the tarball, because otherwise I’ll never be able to reproduce this tarball. And good luck if the repository gets converted from svn to git, on ever reproducing exactly what you had in that tarball. And if you’re reporting a bug to another package maintainer, that their particular packages breaks on eglibc but not glibc, and in order to reproduce it, “First go do an svn checkout of the source, and checkout out r2462″, rather than “Download v2.3.10 of this package”.
In that same message as the first quote:
They are not an end-user product for ordinary GNU/Linux distribution users, and are not useful to build on their own without the rest of the system using them, but are something for those building a GNU/Linux system from scratch who have the expertise in the many different areas of such a system needed to do so and avoid the many pitfalls that arise in the process.
That’s equivalent to, “Real men code in binary”. It’s a useless statement. But thankfully, someone clearly outlined what it would take to make a release:
There is no such thing as an EGLIBC release; a tarball claiming to be such would be masquerading as something that does not exist. It would be up to the EGLIBC Consortium if they wish the project to start providing releases or snapshots as tarballs (but if they do then it would make no sense to take them from third parties; building a tarball is easier than verifying one). As with the lack of releases, there is no release number scheme for identifying points on branches other than SVN revision numbers; the only meaningful naming system would be to name snapshots (created by svn export of the branch directory – not the libc/ports/localedef subdirectories – followed by touching checked-in generated files to get timestamps in the right order) after the branch version and the SVN revision number of the most recent revision on the branch at the point the snapshot is created, e.g. 2.10-8454. (The branchpoints are definitely bad points to use; only tip of a branch might be sensible for creating snapshots.)
Good luck reproducing that. Ever.
And later on in the thread:
Once the version number on trunk has been increased for development of the next version and new symbols have started being exported at the new symbol version, and any merge to the branch from FSF GLIBC around the same time as the merge of those changes from FSF GLIBC to trunk has been done, it’s then reasonable to suppose that the branch has a stable ABI.
So we have to closely follow the SVN checkins, in order to see whether or not something is stable, rather than a developer who knows far more about what they’re doing with that project, going, “Well, looks stable to me”, cuts a release, makes an sha1sum of it, and sticks it on the website, probably about 10 minutes of work.
What’s saddening is the next statement:
These seem very curious to me; I’d take the view that uClibc version numbers have little meaning, releases are infrequent and there are no more guarantees of binary compatibility for “releases” than for any other version, so the natural approach with uClibc would to me be to stablise a current snapshot of uClibc development (where you can fix a revision you use as a basis for your stabilising patches, but you may as well start from the most recent development revision available, and will expect to have to patch it to fix issues found in validation in any case).
Sadly, uClibc doesn’t have a very rigorous release schedule, and I’ll completely agree with Joseph Myers there. However, that’s not a justification for not having any releases, or not doing your own release schedule. Just because uClibc maintainers have a bad practice, just give you carte blanche to do the same. And he’s missing a rather critical point, uClibc has releases, at least.
Also, I think the last point that’s pretty obvious, eglibc is attempting to make glibc embedded, basically. I don’t see the glibc developers claiming that they don’t need release tarballs, just grab it from svn.
Comments
I believe your comment about this “release” style making it hard to reproduce releases or identify versions is partly a red herring.
It is a red herring, because end users will certainly have versions of the library. For example, the machine I’m using now has GNU libc version “2.9-25″ installed. That is nonsense to the glibc hackers, but it is meaningful to Debian. I can report bugs against version “2.9-25″ of glibc to my distro, and they will handle dealing with mapping that somehow to the upstream.
OTOH, from your quote, it seems that there is no easy way to refer to a single source checkout, and that is disturbing. I mean, even with the Linux kernel, I can refer to a git commit ID.
Okay, end-users will report bugs initially upstream to the Debian/Ubuntu/Gentoo/et cetera distribution maintainers, who have to interface between Mr. Drepper/et al and their folks for glibc.
But that’s just insulating the problem. Debian or whichever distribution had to grab a random repository checkout, and basically fork it from the repository, and closely monitor both the mailing list and the repository. I’ll agree, if I’m the glibc/gcc/et al maintainer for Debian, I probably should keep a fairly close eye on that, to an extent. But there is no easy markings of, “Okay, here’s the next stable drop”, at all.
From the point of view of someone who was looking at adding eglibc support to a software project, which requires building from source, it’s troublesome. I have to basically ask on the list, “What should I bother looking at as far as stable?” Because trying to cross-compile a C library is painful enough without having to deal with instable checkouts.
Related, I still love Joel on Software’s recent statement, Shipping is a feature. A really important feature. Your product must have it, from The Duct Tape Programmer
Lastly, yes, the fact that it appears to be a random shot process to reproduce a tarball of the repository, is extremely disturbing.
> They are not an end-user product
I agree that paragraph is a useless statement. Since when is the stock_glibc_ an end-user product “useful to build on their own without the rest of the system”? By that argument, glibc itself shouldn’t bother to have releases. (Once again, “my project is _special_!”)
Here’s a follow-up to the duct tape programmer, by the way. One from the guy who wrote the book with the Zawinski interview Joel was replying to:
http://gigamonkeys.com/blog/2009/09/28/a-tale-of-two-rewrites.html
And one from Zawinski himself:
http://jwz.livejournal.com/1096593.html
Dont worry. They will ignore you.
They will claim that their target audience is only distributions, never any single user.
Been there, heard that.
Moving on …
If the EGLIBC commiters create a tag for each major release within SVN why is that not sufficient? You can then checkout that tag, and work with it. Yes you’ll have to look somewhere to determine which is the latest tag [can't be that difficult]
Except they don’t tag. They make branches for eglibc 2.8, 2.9, et cetera, but those are also moving targets. And the developers even recommend not focusing on a branch, merely on trunk, which is even more of a moving target.
Thats true for any project that is sensibly managed and use care in choosing what to backport onto the stable branches.
Trunk is stable; its not a hard concept to grok. I use Boo, a python-inspired CLR language, and it has a similar model to eglibc, it sounds like. Boo occasionally kicks out releases, but everyone uses SVN, and reports issues against the SVN revision number. It should “just work” and if its not working, make sure to update, and see if its still not working. If you need to start some advanced destabilizing work, get a branch. Theres colossally large suite to test against regression, and if something does regress, write a suite for it and never deal with the problem again. I see nothing wrong with this notion of a live code-base.