Official presto repositories for Rawhide

Josh Boyer jwboyer at jdub.homelinux.org
Tue Jun 19 20:43:37 UTC 2007


On Tue, 2007-06-19 at 16:35 -0400, Jeremy Katz wrote:
> On Tue, 2007-06-19 at 15:29 -0500, Clark Williams wrote:
> > Jeremy Katz wrote:
> > > On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote:
> > >> On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote:
> > >>> The question is where in the process does it make sense to generate
> > >>> the deltas.  Do we do them in the build system (the koji level)?  Do
> > >>> we do them in the update system?[1] Do we do them at tree compose
> > >>> (mash) time?  Each has tradeoffs... not sure which is really the
> > >>> best.
> > >> The problme domain are the limited bandwidth of end users, so you want
> > >> it to run on what end users consume. This can be different for
> > >> released versions vs rawhide, but in general released versions would
> > >> only perform this on updates-released (not updates-testing) and
> > >> for rawhide on everything.
> > > 
> > > Yeah, it's easy to see that deltas for -updates and -updates-testing[1]
> > > from the release and probably the last update make sense[2].  rawhide is
> > > definitely the trickier to figure out where to draw the line.
> > 
> > Do you even want to draw that line in rawhide? To me, rawhide is
> > dangerous enough that trying to add delta updates on top of it is just
> > asking for (more) trouble.
> > 
> > I think that -updates* is perfect for deltas, because the latest package
> > is almost always going to be an iteration on the previous version(s).
> > But rawhide might be a complete version jump, or changing toolchains, or
> > trying something just plain whacky. The potential for space saving due
> > to commonality doesn't seem to be there for rawhide.
> 
> The space savings benefit isn't really the win for rawhide -- it's more
> the testing base and being able to ensure that things continue to work.
> Because nothing sucks more than doing a release and then realizing that
> some part doesn't work because it's not a regular part of your devel
> infrastructure.

+10

josh




More information about the fedora-devel-list mailing list