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
