This is the mail archive of the
mailing list for the glibc project.
Re: glibc-2.8 tarballs?
Ulrich Drepper <email@example.com> wrote:
> Allin Cottrell wrote:
> > Thanks for the tip. Somehow I feel more comfortable building
> > glibc from an "official" versioned tar.gz, though maybe that is
> > just superstition on my part.
> Tarballs are a completely outdated concept. I've said multiple times
> that I won't waste my time on them. Tarballs are static. If I would
> have made a 2.8 tarballs then I shortly afterwards would have had to
> made 2.8.1 and perhaps more. There are always going to be changes.
> That's what appropriately-tagged branches in CVS are for. You take the
> latest version of the release branch and you know you have the version
> which you are intended to use.
How is that substantially different from getting the latest-numbered
tarball from a directory, except that it is much harder to list CVS
tags than list a directory? (How do you list tags across a whole
repository in CVS anyway? CVS usually only shows tags per file. How
do you find the tags you're intended to use among all the
You can easily get a version other than the one you are intended to
use if you forget to give the -P option to "cvs co", in which case you
get a glibc source tree that will not build. By the way, the
instructions for checking out of CVS on http://sourceware.org/glibc/
are missing the -P option.
Tarballs may be outdated but they are widely supported by tools; more
so than CVS. Some people consider CVS to be outdated.
Tarballs can be md5summed; there's no standard equivalent for a CVS
tag, and CVS allows tags to be removed. Tarballs can be easily
mirrored; doing that for CVS is not trivial.
The CVS port is often blocked by firewalls.
If you don't want to upload a tarball, perhaps someone else can be
given access to do that? The same goes for updating
http://www.gnu.org/software/libc/, which currently states that "The
current version is 2.7".