PDA

View Full Version : Some ubuntu packages need to be protected



sandyd
July 3rd, 2010, 04:18 AM
I believe that there should be some packages in ubuntu that **should** be protected, meaning that the user will have to comfirm the removal, after reading its possible effects.
This can probably stop the amount of people from removing network-manager &like

1. Synaptic/Software Center should emit warnings to users if they attempt to remove a package that could possibly cripple their system, along with the possible effects of removing it. This warning can be turned off through the editing of synaptic settings or from a config file if the user doesn't find them useful.

2. Cache Network-Manager/Other important apps in the apt-archives as part of the postrm script

A lot of users want to try another networking manager such as Wicd to see if it would fix their networking problems. However, if it doesn't, and they are left with no internet, they will have to manually copy over network-manager on to the computer. This is highly non-user friendly behaviour. If network-manager is in the apt-cache, reinstalling it should be a breeze. The network-manager takes up less than 1mb here, so there shouldn't be problems regarding space

3. Synaptic/Software Center should have a "undo changes" option.

I have seen a lot of users simply click "ok" even though they were unintentionally removing tons of packages. In the end, they would have to look through the logs for the packages, which is also highly user-unfriendly behaviour. The "undo changes" button would allow users to undo changes "a step at a time", without jumping around, in order to prevent them from making a bigger mess. This also allows users to remove packages that may have fried their system without them needing to remember the packagename
[...] (http://brainstorm.ubuntu.com/idea/25328/)

All of this may seem like a long haulover, but it is better for newcomers to Linux (Most of this stuff won't affect experienced users anyway because of the option to turn these warnings off)

Vote Here -> http://brainstorm.ubuntu.com/idea/25328/

chessnerd
July 3rd, 2010, 04:22 AM
Agreed.

I actually uninstalled the network manager to install the LX Network Manager and, when I had trouble with the LXNM, I couldn't reinstall it. Eventually, I got the LXNM working, but still, I could have broken my system.

3rdalbum
July 3rd, 2010, 04:27 AM
Some people purposely remove Network Manager, although I do question their reasons to.

Python should definitely be protected. Lots of people install Python 2.5 and remove 2.4, ignoring the warnings that 200 packages will be removed, and then their system is borked.

earthpigg
July 3rd, 2010, 04:39 AM
this is all already possible, but only for nerds like us and those willing to become nerds like us.

general outline of your idea, assuming the user is using default/intended/noobfriendly ubuntu methods of doing stuff:

1)
any package that is a dependency of ubuntu-desktop, when removed in the software center, will automatically be first downloaded to /var/cache/apt/archives.

2)
the software center needs some new functionality that we shall call "undo software changes" or something like that. it looks at the log files in /var/log/apt, an streamlines the process of undoing things. a good start could be a simple list of things done/undone that have been noted in the /var/log/apt log files, with little check boxes next to them. right click and "undo this" or "redo this". i would advocate that it only allow the user to do these things in reverse-chronological order, and disallow skipping things. if you did stuff that screwed ur computer up, then installed wesnoth, then want to undo the stuff that screwed ur computer up... reverse order. so: first you must "undo" installing wesnoth wesnoth, then you can undo whatever it was you did.

sounds annoying, but since all mistakes can obviously not be anticipated, it will make "undo software changes" less-likely to be as damaging as the current "computer janitor" is when used by non-nerds. if you let people jump around and undo package changes, they will do themselves more harm than good. someone that is knowledgeable enough to exactly identify what they did that screwed things up by reading the apt history logs... wont be using ubuntu software center to repair his/her system, anyways. so, for everyone else, ubuntu software center could let you undo all the package changes one set at a time in reverse chronological order.

leave dotfiles in place, of course, unless the user selects "completely undo this change".

earthpigg
July 3rd, 2010, 04:42 AM
Python should definitely be protected. Lots of people install Python 2.5 and remove 2.4, ignoring the warnings that 200 packages will be removed, and then their system is borked.

i have the controversial opinion that Linux should allow multiple versions of the same package in cases like this. i don't give a damn if it is theoretically "less elegant", nor do i care how much it bothers OCD types.

it's practical.

the package manager needs to ask itself: "are there any packages installed that claim to require this specific version of this package?"

if the answer is yes, than install the new package while keeping the old one. (instead of uninstalling 200 packages and then installing the new version of _____).

Dustin2128
July 3rd, 2010, 04:46 AM
I do think it should be disabled by default, but to be completely unremovable, that's wrong. And is the system janitor really suggesting removal of vital packages? If so, I don't think it should be included in 10.10/11.04 (unless/until its fixed).

sandyd
July 3rd, 2010, 05:11 AM
I do think it should be disabled by default, but to be completely unremovable, that's wrong. And is the system janitor really suggesting removal of vital packages? If so, I don't think it should be included in 10.10/11.04 (unless/until its fixed).

it doesnt actually remove network-manager. It just removed one of network-manager's dependencies which caused network-manager to be removed as well. this is what we call "dependency hell". as for the unremovable section, were not really making it non-removable. were just caching the app, so we can install it later even if there are distasterous consequences associated with the app removal (if you remove network-manager, you will have no internet, and downloading each individual package and its dependencies becomes a pain in the ***)

sandyd
July 3rd, 2010, 05:19 AM
i have the controversial opinion that Linux should allow multiple versions of the same package in cases like this. i don't give a damn if it is theoretically "less elegant", nor do i care how much it bothers OCD types.

it's practical.

the package manager needs to ask itself: "are there any packages installed that claim to require this specific version of this package?"

if the answer is yes, than install the new package while keeping the old one. (instead of uninstalling 200 packages and then installing the new version of _____).

some of the newer versions of python, such as the one in lucid, depreciate a hell lotta stuff. we are definately looking for trouble if we try to install the new version of python. but then again, why can't we make the two versions of python coexist peacefully?

NightwishFan
July 3rd, 2010, 05:55 AM
Part of the reasons is that currently Debian/Ubuntu treat programs classified "recommend" as dependencies. You can turn this off in Synaptic. Go to Settings -> Preferences, and uncheck "Consider recommended packages as dependencies." It becomes much easier to trim programs this way. You can re-enable it when you are done. It requires a bit more expert-ness though.

Dustin2128
July 3rd, 2010, 05:58 AM
http://www.synthstuff.com/mt/archives/medtees-ocd.jpg

Must..... resist... urge.. to... straighten.... pencil... 8-[

NightwishFan
July 3rd, 2010, 06:10 AM
I couldn't I have this problem. :)

sandyd
July 3rd, 2010, 06:38 PM
bump

Rubi1200
July 3rd, 2010, 06:47 PM
I actually believe that some packages on the system should be prevented from being removed.

One of the fatal mistakes that occurs a lot of times is removing network-manager, either through dependency hell, computer janitor, or by some other means. A good idea would be to for the apps that are important, and removal will become a fatal mistake, the postrm script should download a copy of the deb into /var/cache/apt/archives along with all its install dependencies. This may use more space, but will prevent newbies from banging their heads against the wall whenver something like this occurs. Since the deb and its dependencies are already in the apt cache, reinstalling network-manager should be a breeze with no harm done.


I actually believe that some packages on the system should be prevented from being removed.

Personally, I am not sure if this is a good idea for the simple reason that it a) takes power out of the hands of the user, and, b) who decides what stays and what goes?


One of the fatal mistakes that occurs a lot of times is removing network-manager, either through dependency hell, computer janitor, or by some other means.
I am seeing this more and more on the forums. I do not understand, or agree, with Computer Janitor being included on the default install. The problems it can potentially cause far outweigh the few MB of space it might free up. But again, who decides if it goes? I edit the menus and remove it; what you don't see won't tempt you right? ;)

Bachstelze
July 3rd, 2010, 06:51 PM
Apt already does that for important packages, it just doesn't think NetworkManager is important, and I agree with that. An Ubuntu system can function very well without it.

earthpigg
July 3rd, 2010, 10:35 PM
Apt already does that for important packages, it just doesn't think NetworkManager is important, and I agree with that. An Ubuntu system can function very well without it.

i would agree that many (most?) ubuntu desktop systems "in the wild" can function very well without it, but perhaps the folks that decide such things should take into account that many (most?) ubuntu netbook or laptop systems "in the wild" aren't very useful with out it -- even if it is only for the briefest of moments between uninstalling network-manager and installing wicd.

Warpnow
July 4th, 2010, 02:26 AM
Can't you just reinstall it from the CD? Popping in the CD usually brings up a menu asking you if you want to load packages off of it. Does it not still do that?

-grubby
July 4th, 2010, 02:34 AM
some of the newer versions of python, such as the one in lucid, depreciate a hell lotta stuff. we are definately looking for trouble if we try to install the new version of python.

Python stuff, when deprecated, still works until they break backwards compatibility. Actually, Python 3 is their first such break in compatibility, and I expect stuff in Python 3, when deprecated, will still work until Python 4.

I can see the rationale though; one particularly nasty situation is one where, for example, an application that was designed with Python 2.4 in mind required a Python library when installed that was put in /usr/lib/python2.4/dist-packages/, but then you upgraded to Python 2.5, the app was run with the default version of Python (2.5, now), and it's library wasn't present in /usr/lib/python2.5/dist-packages.



but then again, why can't we make the two versions of python coexist peacefully?

On my Ubuntu server, I have Python 2.6 and Python 3.1 co-existing peacefully. However, when I try to install 2.5, it gives me a the no installation candidate error. It would definitely be nice if apt was less picky about these kinds of things. As far as the user in my example above is concerned, Python 2.5 isn't really an upgrade when their app is broken on it.

Warpnow
July 4th, 2010, 02:41 AM
Some packages have new versions, and some versions have new packages. You can only install the ones with new packages side by side.

GCC, for instance, usually has new packages.

koenn
July 4th, 2010, 12:36 PM
In a Debian/Ubuntu type environment, you should never get this type of trouble, if you install from official repositories for the release you're running. Inconsistencies in dependency handling shoud be filed as bugs against the offending packages. Or the release manager really screwed up.
In my experience, this is extremely rare.

If you get "dependency hell" from installing/upgrading to software that is not native to the release you're running, maybe you've chosen the wrong distro, or release, or ...

Otoh, maybe the release-centric approach of Debian (and even more so Ubuntu) is not an adequate solution anymore. But in that case, ad-hoc stop gap solutions such as 'protecting packages' is just a workaround that will produce maintnance hell for the package maintainers/release managers as the number of packages that need protection, grows. An overhaul of the release and software distribution approach might be a better idea.

davec64
July 4th, 2010, 12:42 PM
i have the controversial opinion that Linux should allow multiple versions of the same package in cases like this. i don't give a damn if it is theoretically "less elegant", nor do i care how much it bothers OCD types.

it's practical.

the package manager needs to ask itself: "are there any packages installed that claim to require this specific version of this package?"

if the answer is yes, than install the new package while keeping the old one. (instead of uninstalling 200 packages and then installing the new version of _____).

I was reading up on Fedora the other day, and they now have a system which allows you to install Python 3 along side Python 3. Perhaps something along these lines will spread!

Noz3001
July 4th, 2010, 01:08 PM
"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn

cb951303
July 4th, 2010, 01:12 PM
I agree. "sudo tasksel remove lamp-server" makes the system unusable because it removes every dependency. if the core packages were "protected", the whole system wouldn't crash because of a bug in a 3rd party application like tasksel (which comes preinstalled btw)

Half-Left
July 4th, 2010, 01:20 PM
"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn

Yep, it's all the rage these days. Stop people from doing this just in-case that happen.

You learn by mistakes, not by locking the system down until no one can do anything

sandyd
July 7th, 2010, 04:52 PM
Yep, it's all the rage these days. Stop people from doing this just in-case that happen.

You learn by mistakes, not by locking the system down until no one can do anything
I am saying that it would be a good idea to add this functionality onto the ubuntu software center (only locking down the software center). you see, people who just want things to work, and want to keep it simple will use the ubuntu software center. the center will prevent them from doing idiotic stuff that will prevent them from making their lives difficult. If their a person who is going to actually tinker, their going to use synaptic, and they can break their systems as much as they want.

samalex
July 7th, 2010, 05:24 PM
I actually believe that some packages on the system should be prevented from being removed.

One of the fatal mistakes that occurs a lot of times is removing network-manager, either through dependency hell, computer janitor, or by some other means.

I ran into this exact thing a few months ago where I installed a package and it uninstalled network-manager. Yeah I probably would've caught it if I read all the messages :-/ I had to download the packages from my wife's laptop and copy them back to my laptop via Bluetooth to get back up and going.

So though I don't think they should be prevented from being removed all together (I don't like my system telling me what I can/can't do), I do think there needs to be a huge warning message or something that tells you that removing X package will impact core functionality of the system.

Sam

aysiu
July 7th, 2010, 05:33 PM
I actually believe that some packages on the system should be prevented from being removed.

One of the fatal mistakes that occurs a lot of times is removing network-manager, either through dependency hell, computer janitor, or by some other means. A good idea would be to for the apps that are important, and removal will become a fatal mistake, the postrm script should download a copy of the deb into /var/cache/apt/archives along with all its install dependencies. This may use more space, but will prevent newbies from banging their heads against the wall whenver something like this occurs. Since the deb and its dependencies are already in the apt cache, reinstalling network-manager should be a breeze with no harm done.
Post it on Brainstorm, and I'll vote it up.

sandyd
July 8th, 2010, 01:52 AM
got it.
waiting for mods -> http://brainstorm.ubuntu.com/idea/25328/

sandyd
July 9th, 2010, 09:19 PM
bump

Rubi1200
July 9th, 2010, 09:27 PM
"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn

I love this!! I am bookmarking this right now.

@ carlee: sorry for the off-topic post but I had to react. :)

Ceiber Boy
July 9th, 2010, 09:57 PM
The first couple of ubuntu os I had a played with until distruction, so that I could learn what I could and could not do, when it went wrong I simply reinstalled it and started again. I keep a copy in virtual that I use for experimental pourposes so I don't crash my main system.

This preventing people from removing stuff sounds very MS and I don't like it. Remember Linux assumes you know what your doing! If you don't know what your doing you should not be doing it.

Penguin Guy
July 9th, 2010, 10:01 PM
I don't like this idea at all, users need to learn not to uninstall stuff unless they know what they're doing.


cache the package locally
All packages are cached by default, you can find them in /var/cache/apt/archives.

aysiu
July 9th, 2010, 10:05 PM
This preventing people from removing stuff sounds very MS and I don't like it. Remember Linux assumes you know what your doing! If you don't know what your doing you should not be doing it. It's not preventing people. It's discouraging people.

If people want to remove packages, they still can, and even more easily using the CLI.