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. 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. > > > Anna added a PPA through Synaptic > Settings > Repositories, which > > upgraded emacs. She didn't like the upgraded version, so she removed > > the repository. She scrambled around for a while, before realising she > > could get her old emacs back by removing it then reinstalling. > > Anna certainly won't be happy when she realizes that her fine emacs > config is gone because the new version upgrade it to a new format the > old version can't understand. > > > Tim added a repository from a random website through System > Admin > > > Software Sources, then updated and was notified that a new version of > > debconf was available. He installed the upgrade, then realised that the > > upgrade had been downloaded from the new repository. Realising he'd > > been tricked, he removed the new repository and assumed that debconf had > > been uninstalled as well. > > We can't protect the users from themselves. I'm sorry, but if Tim add a > random (untrusted) package source without thinking, then he deserves a > little pain in undoing it. Otherwise people won't learn it if Ubuntu > makes everything ok what they break. > Although the example of a random package may be a bit extreme, the concept still survives. > > Bob, thinking that a Debian-based distribution should be okay with > > Debian packages, followed command-line instructions to create > > /etc/apt/sources.list.d/debian-unstable. Once his Ubuntu/Debian hybrid > > was installed, he rang his technical friend to clear up the mess. The > > friend tried every "apt-get" command he knew, before gradually realising > > that he had to run "apt-cache showpkg <name>", find the package version, > > do "apt-get install <name>=<ubuntu version>", and repeat many, many times. > > There a way too many ways to break a installation. Who breaks it, can > keep the parts. I respectfully disagree. User Case. Jacob upgraded to a -updates package. This upgrade seems to have broken something (perhaps a regression), and he wants to get back. If what you state were to be generically valid, then Ubuntu must keep the parts.
signature.asc
Description: This is a digitally signed message part
-- 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
