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

[Fedora-packaging] PackagingDrafts/DisttagsForRawHide (was: fc5.90/fc5.91/... disttags and automated rebuilds (was: Mass rebuild of Extras packages for FC6?))


I summarized the pros and cons of using disttags in rawhide matching
to rawhide's internal version in here:


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: pgpbFsDjQtpyl.pgp
Description: PGP signature

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