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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
