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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

        Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux