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.
>
> 1) rpm signing w/ sha256sum
> 2) New toolset feature to speed up dynamic lib linking by 50%~
> 3) get all packages built through new build system (brew)
Change the last point to
3) 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.
--
Axel.Thimm at
ATrpms.net