Notice of intent: patching glibc

[Adam Williamson]

On Sat, 2011-09-03 at 13:43 +0200, Jakub Jelinek wrote:
> On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote:
> > > Fedora glibc sources are from git, and the bit diff is just generated
> > > diff between the upstream snapshot and corresponding Fedora snapshot,
> > > sans a few Fedora-only directories (which are packaged as extra tarball).
> > 
> > That's not a reason.
> > 
> > Why not keep the Fedora branch in git and make patches from it:
> > 
> > https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/
> > 
> > This method is quite probably simpler than the one you're using now.
> 
> glibc is doing it that way for many years, even when it was diffing upstream
> CVS trunk vs. Fedora CVS branch, not sure if the Fedora changes from CVS era
> would result in something reasonable with your tricks, but moreover what
> glibc does now is fully scripted in the Makefiles and it would be extra work
> to change it to something different.  I'd say it is up to the Fedora glibc
> maintainer to do it the way he prefers to (which is not me for a couple of
> years now).

Well, not entirely. There are the packaging guidelines. I took a look,
and interestingly I can't find anything in there specific about how to
format patches: seems that 'one-patch-for-one-change' is just a
convention, albeit a very deeply-embedded one with most packagers.
However, there's this, on sources:

"There are several cases where upstream is not providing the source to
you in an upstream tarball. In these cases you must document how to
generate the tarball used in the rpm either through a spec file comment
or a script included as a separate SourceX:. "

There is no indication in the glibc spec of what the Fedora 'source' is
or where it comes from; anyone coming to the spec without prior
knowledge will be confused, as I was, as to the nature of this tarball.
Its nature and method of generation should be documented in the spec.
I'm not sure if the 'Makefiles' used to generate glibc.spec are part of
upstream glibc source - if so, a simple comment which says 'look at
foo/bar/Makefile in source0 for details' would be fine, if not, the
Makefile should probably be included as another Source, as suggested in
the guideline.

There's also this, for patches:

"All patches in Fedora spec files SHOULD have a comment above them about
their upstream status. Any time you create a patch, it is best practice
to file it in an upstream bug tracker, and include a link to that in the
comment above the patch."

This is a SHOULD not a MUST, but really, it's pretty basic - I'd say
it's more important in this case as the glibc patch is not a typical
one, and I think would leave most readers of the spec file confused. Its
nature and source really should be indicated by a comment. Too, there's
no indication of the 'upstream status' of the Fedora changes; once you
know they form a git branch, you could go upstream and look at the git
commit logs to discover the *nature* of the change, I suppose, but not
necessarily its *upstream status* - i.e. whether a change made in the
Fedora branch of git is Fedora specific, or is planned  to be merged
into master, or what.

To look at things at a higher level: it's clearly the goal of the
guidelines that any interested party (with sufficient basic knowledge)
who comes along and checks a Fedora package out of git should be able to
_understand it_, and this includes finding out where all the stuff that
goes to make up the package actually comes from. glibc spec clearly
doesn't achieve this goal; the casual browser is left looking at a
gigantic patch and a mystery tarball and wondering where they came from
and what they do, as I was. This makes glibc not at all raptor-proof,
and not very amenable to outside review or improvements, which is rather
against the spirit of an open source, community project.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net