yep, at this step, I wanna hammer it down with testing, before we add all sorts of nice utilities around managing the drpms we'll get. Ideally, we should have some server hosting core/extras/updates drpms, and test upgrading from that as much as possible. Whether, automatically, or with the aid of brave individuals. All we have to say is "Hey it can eat your kittens" :) <div>On 3/12/07, Jonathan Dieter <<a href="mailto:jdieter@gmail.com">jdieter@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Mon, 2007-03-12 at 09:31 -0400, Ahmed Kamal wrote: > The idea is NOT to provide incremental updates. i.e. drpms will always > upgrade some version to latest. You should never need to install > several drpms to reach "latest" state. > I am thinking it would be best to provide at least 2 drpms > n-1 => n (previous to latest) > and > General Availability (FC6 isos) => latest > > If this gets popular, we might provide n-2 => n drpms for slow > updaters > There's a neat little utility included with deltarpm called combinedeltarpm that will combine two drpms into one (i.e. abiword-2.0-2.1.drpm + abiword-2.1-2.2.drpm = abiword-2.0-2.2.drpm) which would provide the n-2 drpm quite easily. We really just need to get it up and running first, though. ;) Jonathan -- fedora-devel-list mailing list <a href="mailto:fedora-devel-list@redhat.com">fedora-devel-list@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/fedora-devel-list">https://www.redhat.com/mailman/listinfo/fedora-devel-list </a> </blockquote></div>