Re: Two packages form Ubuntu 8.04 (amd64)
Hi, Thanks for your interest in contributing to Ubuntu. 2009/8/3 Jean-Christophe Cazenave cazen...@math.jussieu.fr: glimpse: http://webglimpse.net , a tool for indexing text files in a tree of directories http://revu.ubuntuwire.com is the place for new packages. bash-4.0: my objective was to use associative arrays (the current man is currently based on bash-3.2 and doesn't tell anything about that, but the online documentation does: http://www.gnu.org/software/bash/manual/html_node/Arrays.html#Arrays). I have compiled it with the whole bunch of currrent patchs. Please get in touch with Debian's Bash maintainer about those patches. -- Siegfried-Angel Gevatter Pujals (RainCT) Ubuntu Developer. Debian Contributor. -- 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
Re: Downgrading packages after removing a repository
On Sat, 2009-08-01 at 19:49 +0100, Andrew Sayers wrote: I've found a bug (or maybe it's a feature request) in apt (or maybe it's in software-properties-gtk). I'd like to get people's opinions about where this is best reported, and what the report should say. 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. Normally this is a minor irritant, but it can be a security issue, or can even make recovery very hard indeed. Here are three user stories to illustrate the issue: I am sort of surprised that there has been no comments here about it. This is -- at least for me -- a clear need, and the user cases are consistent with my own experience. If we add in the mix the usual testing with PPAs, having a *standard* way of going back is not only desirable, but actually needed. I would say that a blueprint would be a good way to formalise this. Would you find this too intrusive? Not intrusive enough? Should I forget about Synaptic now that AppCenter is coming along, or should I focus on getting functionality into APT that can later be made available through the GUI? I do not know if too much/little intrusive, but I certainly like the idea, and I do think having a way of returning to a known, fully-supported state should be a *basic* requirement. This not only helps the casual user, as those that live on the bleeding edge. Thank you for the proposal. 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
Re: Downgrading packages after removing a repository
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). 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. 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. 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. Regards, 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
Re: Downgrading packages after removing a repository
You make a good point about breakage when packages are downgraded. But it seems a little disingenuous for us to bend over backwards to make unsupported upgrades possible (adding a software sources menu item, putting PPAs in Launchpad, creating /etc/apt/sources.list.d/ and so on), then for us to walk away when those upgrades make systems unusable. I also take your point that pain is an important way of communicating danger to users. But making a system unusable seems like pushing a man off a cliff to warn him about the dangers of falling. I would expect the message to be at least as effective if we had a GUI to say warning: may cause breakage on upgrade, warning: breakage caused on downgrade, and breakage evident from the loss of configuration data. If that's acceptable to you, and if C's blueprint idea seems okay, then I'll include the GUI suggestions in the blueprint. - Andrew -- 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
Re: Downgrading packages after removing a repository
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
