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. > > > > > > 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
Attachment:
pgp1gBZa46JpN.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
