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