Heads-up: brand new RPM version about to hit rawhide

Doug Ledford dledford at redhat.com
Mon Jul 14 17:01:12 UTC 2008


On Mon, 2008-07-14 at 16:48 +0000, Kevin Kofler wrote:
> Doug Ledford <dledford <at> redhat.com> writes:
> > First, before I respond to the rest of this, keep in mind that the
> > "overwhelming majority" of packages needs to be quantified.
> > Furthermore, at least one very significant package (the kernel) does not
> > massage files at all between SCM tag and tarball.  And to be honest, I
> > would be very surprised to find many projects that do have any
> > significant difference between a tagged release in the SCM of their
> > choice and their tarballs.  So I would like some examples please, which
> > shouldn't be hard to come up with since it is the "overwhelming
> > majority" of projects that obviously think when they tag something in
> > their SCM it doesn't need to match the tarball they make with the same
> > tag version...
> 
> Many packages don't have a public SCM at all; some have a private SCM, some 
> one-man projects have no SCM at all. (For example, there is _no_ SCM for 
> Quarticurve and Quarticurve-KWin, unless you call fully exploded copies of old 
> versions sitting around on my HDD an "SCM".)
> 
> And even if they use an SCM, they can:
> * make releases without tags: For example, the weekly trunk snapshots of KDE 
> don't get tags, nor do the extragear tarball releases.
> * modify tags: This is particularly common in Subversion which allows using a 
> tag like a branch. KDE normally uses the following workflow:
> 1. tag release
> 2. prerelease tarballs from the tags to packagers
> 3. fix any showstoppers by merging fixes to the tag
> 4. respin tarballs for the modules which were thus fixed
> 5. make the release public
> so the contents of the tag can change between when we first build the package 
> and the public release of the new version. The checksummed tarballs handle this 
> robustly, we can just upload a new respun tarball with a new checksum. But 
> automatically picking up a respin can break the build because sometimes we had 
> a showstopper fix as a patch, which of course no longer applies if the release 
> is respun including the fix, so building from whatever the current contents of 
> the tag are rather than from whatever we used breaks reproducibility of builds.
> * require postprocessing: It's not just autotools which are a problem there. 
> For example, the KDE extragear releases use a fairly clever script collecting 
> translations from elsewhere in the SVN repository.

I understand that some packages don't have an SCM, or that they use a
totally unsuitable SCM for distributed repo management.  It's a shame
they won't be able to make use of the new functionality without first
making internal changes to their own work flow processes, but it's
hardly a reason not to make the new functionality available to others.

So far, we've heard of kernel, the Infiniband and MPI stacks, and
probably gnome that could make use of this change.  Myself, I think that
is sufficient to be worthwhile regardless of the state of KDE or the
overwhelming majority of packages.  You get enough benefit out of just
the listed packages alone to make the changes of worth.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080714/1657d9df/attachment.sig>


More information about the fedora-devel-list mailing list