fc5.90/fc5.91/... disttags and automated rebuilds (was: Mass rebuild of Extras packages for FC6?)
On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote:
I suppose a lot of people won't like the topic I'll bring up with this mail but we IMHO should discuss this nevertheless.
Jesse Keating schrieb:
I've been requested to rebuild every Core package for a few reasons.
- rpm signing w/ sha256sum
- New toolset feature to speed up dynamic lib linking by 50%~
- get all packages built through new build system (brew)
Change the last point to
- get all packages build with the new and reduced set of packages
installed in the default mock buildroot
All the above three could be automated for packages using %{?dist}, if the disttag would propagate in fedora time as well. E.g. the internal release version of FC6test1 is 5.90, if the disttag was matched to this, we would have automated rebuilds for each test release and for the final release as well w/o anyone having to do anything about it (sparing bugs of course).
If rebuilds are needed more often (because gcc was upgraded in between) then disttags could look like 5.90.1 to indicate a rebuild between test1 and test2. Before test1 rawhide had the version 5.89, so we're covered in that area, too.
If we're going to mass-rebuilt (and therefore touch each specfile), could we consider using such disttags for rawhide/test releases from now on? E.g. make %{?dist} become 5.90.1 is the mass rebuild is before test2, or if the mass rebuild coincides with test2 go 5.91.
It doesn't cover packages not using disttags (so it's perhaps another incentive for these packagers to use them) and due to everything being automated doesn't serve as a way to ping absent packagers. But that was only a side effect of the humanly powered mass-rebuilds, which will be managed differently anyway in the future.
Hi,
I summarized the pros and cons of using disttags in rawhide matching to rawhide's internal version in here:
http://www.fedoraproject.org/wiki/PackagingDrafts/DisttagsForRawHide
I've added Jesse's and Jason's reservations, too.
On Sat, Jul 01, 2006 at 01:34:29PM +0200, Axel Thimm wrote:
On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote:
I suppose a lot of people won't like the topic I'll bring up with this mail but we IMHO should discuss this nevertheless.
Jesse Keating schrieb:
I've been requested to rebuild every Core package for a few reasons.
- rpm signing w/ sha256sum
- New toolset feature to speed up dynamic lib linking by 50%~
- get all packages built through new build system (brew)
Change the last point to
- get all packages build with the new and reduced set of packages
installed in the default mock buildroot
All the above three could be automated for packages using %{?dist}, if the disttag would propagate in fedora time as well. E.g. the internal release version of FC6test1 is 5.90, if the disttag was matched to this, we would have automated rebuilds for each test release and for the final release as well w/o anyone having to do anything about it (sparing bugs of course).
If rebuilds are needed more often (because gcc was upgraded in between) then disttags could look like 5.90.1 to indicate a rebuild between test1 and test2. Before test1 rawhide had the version 5.89, so we're covered in that area, too.
If we're going to mass-rebuilt (and therefore touch each specfile), could we consider using such disttags for rawhide/test releases from now on? E.g. make %{?dist} become 5.90.1 is the mass rebuild is before test2, or if the mass rebuild coincides with test2 go 5.91.
It doesn't cover packages not using disttags (so it's perhaps another incentive for these packagers to use them) and due to everything being automated doesn't serve as a way to ping absent packagers. But that was only a side effect of the humanly powered mass-rebuilds, which will be managed differently anyway in the future.
packaging@lists.fedoraproject.org
-
Axel Thimm