Official presto repositories for Rawhide

[Axel Thimm]

On Mon, Jun 18, 2007 at 09:23:31PM -0400, Jeremy Katz wrote:
> On Mon, 2007-06-18 at 21:19 -0400, 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]

Actually not updates-testing for two reasons:

a) it is and will not really ever become a bandwidth critical area,
   since only very few people (in relation to updates-released) will
   be using it, and the bandwidth limited will certainly not be on the
   top list for other reasons.

b) updates-testing may contain parts that will be doomed as
   unreleasable (that's why we have a testing stage at all). Having
   all deltas makes it possible for the user to resurrect all old
   releases including the broken ones. So when a user may think he
   downgrades to a previous stable release he may be downgrading to an
   updates-testing one.

b) can be handled by not inheriting the deltas from updates-testing, of
course, but one needs to be aware of that. E.g. while updates-testing
may have foo-1 -> 2 -> 3 -> ..., updates-released will have foo-1 -> 3
-> 7 etc.

> > from the release and probably the last update make sense[2].  rawhide is
> > definitely the trickier to figure out where to draw the line.
> > 
> > The more I think about it, the more I think we want it integrated kind
> > of similar to how the signing works -- koji plays a role but is driven
> > with external info to know what to create deltas for.  The deltas are
> > then associated with a given nevra of a package and stored along side
> > them.  Then, when we mash a tree (be it updates or rawhide), there's
> > policy to get the appropriate deltas given the policy and koji generates
> > them behind the scenes if needed.
> 
> Should have been..
> 
> [1] Since we want people making sure the deltas work when they're
> downloading from -updates-testing too!
> 
> and the following should have been [2]...
> > [1] Arguably, the answer is to do deltas for foo-1 -> foo-2, foo-2 ->
> > foo-3, foo-3 -> foo-4 and foo-1 -> foo-4.  The last can be generated
> > from just combining the earlier three for convenience of the entirely
> > not updated user.
> 
> Jeremy
> 

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070619/16196a49/attachment.sig>