On 2009-08-04 13:14:25 -0500, C de-Avillez wrote: > On Tue, 2009-08-04 at 17:56 +0200, Michael Bienia wrote: > > On 2009-08-01 19:49:33 +0100, Andrew Sayers wrote: > > > When you add a repository to your computer, then remove that repository, > > > it's not obvious how to downgrade packages that are no longer available.. > > > > Downgrades are not supported, while in practise they work in most cases. > > Offering such a downgrade option will probably lead to bugs about broken > > downgrades as people will assume that it should work. > > > > Downgrade will certainly fail if the format of user data has changed > > (e.g. a new database format or config file format). Assuming that the > > new version will upgrade the data to new format on the first run, the > > data won't be usable after a downgrade anymore (the old version doesn't > > understand the new format). > > Indeed. Some options seem to apply, though: offer to replace the current > configuration with the maintainers one; warn the user the the current > user data format is incompatible with the one provided in this version, > and that the user will have to *manually* recover; etc, etc. > > Still, this is not a reason *not* to provide such service. We already > provide a similar service in the other direction. Also, I am not aware > of API/ABI changes *within* a version (or Ubuntu release) being a common > case. So, for most cases, we are talking only about updates/downgrades > *within* a version/release.
If you limit this to use-cases with requirements (like only updates from -security or -updates) when it should be possible to downgrade, then it's easier to do than a "generic downgrade" like it sounded in the first mail. > Nevertheless, I agree that downgrading to a *previous* version is a > potentially dangerous situation, and should not be offered to either the > casual or experienced user. > > > > > While not the best solution, make downgrades only available to those > > who know that downgrades might fail and that they're left alone in such > > a case, will hopefully prevent that people assume that downgrades will > > always succeed. > > Although this is the current practice everywhere (not only on Ubuntu), > and I am not aware of any implementation of this idea, the proposal > still *can* bring value to the table. I certain would love it. And I > think that this would bring even more value for Ubuntu. Surely, making downgrades more easily sounds fine. But like any other feature it needs developers time and also testing that it works and not breaks even more horrible. And as developer time is a rare resource one needs to use it wisely. And using it on a feature which will be only used by a few people while there are enough bug reports in Launchpad about other bugs (incl. upgrade problems) doesn't sound wise to me. > User Case. Jacob upgraded to a -updates package. This upgrade seems to > have broken something (perhaps a regression), and he wants to get back. This is a very specific use-case where downgrades might be possible. The involved packages and versions are pretty well known and the changes to a package between release and release-updates are rather small. Doing the same for -backports which might include complete new upstream versions is on the other hand not so easy anymore. > If what you state were to be generically valid, then Ubuntu must keep > the parts. For -updates Ubuntu tries its best to avoid regressions and in case a severe regression slips through stops the specific update. Michael -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
