Re: [issues] Why eglibc does not provide tarball?

[Brett Neumeier <bneumeier@xxxxxxxxx>]

Thanks for your thoughtful reply; as you'll no doubt have noticed, I
have been considering how best to respond for some time.

On Sat, May 16, 2009 at 2:10 PM, Joseph S. Myers
<joseph@xxxxxxxxxxxxxxxx> wrote:
> There is no such thing as an EGLIBC release; a tarball claiming to be such
> would be masquerading as something that does not exist.

That is an interesting statement!

I had not considered that the Consortium members might not think of
the branches in the eglibc SVN repository as maintenance branches for
eglibc releases. They certainly have the superficial appearance of
being exactly that, since they are named things like "eglibc-2_10".

> 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).

I absolutely agree with this. If the EGLIBC Consortium decides to make
release tarballs available, it would make me very happy -- and, I'm
sure, other people who, like me, prefer to use original upstream
sources without modification in building our own systems, rather than
relying on other people to package those systems conveniently. And, as
you point out, it would not be particularly difficult for someone on
the Consortium to prepare such tarballs! I hope that happens; it would
be the ideal outcome of this discussion from my perspective.

I made my earlier offer with the presumption that nobody on the EGLIBC
Consortium wishes to undertake the work of creating release tarballs
and maintenance patches, but perhaps would not mind hosting such
things. If that is the case, I would be delighted to do the drudge
work of constructing those release artifacts and uploading them to the
appropriate location.

In the meantime, since I do find tarballs to be valuable, my intention
is to continue creating source tarballs; and I don't see any
particular reason not to make them available publicly, for anyone who
wants to use them. Does that make sense? Is there some reason you can
think of that I shouldn't do that?

> 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 [..]
> 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.)

The problem with creating snapshots based on the tip of the branch is
that the tip keeps changing. That's why I opted to create snapshots at
the branchpoint, and provide update patches that encapsulate the
further commits on those branches.

Using the SVN revision number in the patch name, to identify
unambiguously which commits are included in those patches, seems like
a good idea. If you look at http://toolchain.freesa.org/eglibc/ you'll
see that's what I've done.

Cheers!

bn

-- 
Brett Neumeier (bneumeier@xxxxxxxxx)