Pacman really made a mess of my system this time :(

Wilco · 2009-04-28 18:42:41

So I tried to remove gnome from my system:

# pacman -Rs gnome
...
:: gnome-vfs: requires gnome-mime-data>=2.18.0-2

# pacman -Rs gnome-vfs
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: libgnome: requires gnome-vfs>=2.24.1-2

# pacman -Rs libgnome
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: evolution-data-server: requires libgnome>=2.26.0
:: libbonoboui: requires libgnome>=2.24.1

# pacman -Rs libbonoboui
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: libgnomeui: requires libbonoboui>=2.24.1

# pacman -Rs libgnomeui
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: gnome-media: requires libgnomeui>=2.24.1
:: gnome-panel: requires libgnomeui>=2.24.1
:: yelp: requires libgnomeui>=2.24.1

# pacman -Rs yelp
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: gnome2-user-docs: requires yelp

# pacman -Rs gnome2-user-docs
checking dependencies...

Remove (1): gnome2-user-docs-2.26.1-1

And it goes on and on. Then after uninstalling GDM the following line stays in /etc/passwd, while it obviously should not:

gdm:x:120:1002:PolicyKit:/var/lib/gdm:/sbin/nologin

So... what's up? Is pacman drunk or something?

Cerebral · 2009-04-28 18:47:53

I don't quite understand what your issue is - it looks to me like pacman is preventing you from removing things that are required by other things. If you want to get rid of gnome and everything that depends on gnome and everything that gnome depends on, then use pacman -Rsc gnome

As for the /etc/passwd, I don't know if that's the expected behaviour or not - I know I wouldn't want pacman removing users automatically from passwd.

Wilco · 2009-04-28 19:00:56

1. I never used the -c option before, but the manual also warns about the -c option so is it really a safe switch to use?

Anyway this seems to work fine so far. Thanks m8!

2.The gdm user should die because what good is a gdm user without a gdm program?

Xyne · 2009-04-28 19:11:35

1. It's safe to use if you know what you're doing. Just make sure that you pay attention during the operation to see what it's about to remove. As with all pacman operations, don't just run the command without thinking or reading.

2. So remove the gdm user. I think it would make sense for packages which create a user to include a post-uninstall message stating that you can remove the user but it's probably unsafe in some cases to remove the user automatically.

Wilco · 2009-04-28 19:21:48

One more question: is this possible?

0. basic system without gnome
1. pacman -S gnome
2. pacman -S gnome-extra

3. pacman -R... gnome-extra
4. pacman -R... gnome

At this point the system should be exactly the same as at point 0. So no gnome or anything related, but I noticed that pacman -Rcs also removed dbus which I still need for other programs.

Anyway, thanks for all the help so far!

Xyne · 2009-04-28 19:33:57

Yes, removing packages in reverse order will work too.

If dbus was included when using -Rcs, then you do not have any packages on your system which explicitly depend on dbus. There's been a discussion about how to handle optional dependencies but there's been no progress. Here was my suggestion: http://bbs.archlinux.org/viewtopic.php?id=62553

Wilco · 2009-04-28 19:52:58

Nice writing about the opt. deps.
Furthermore, pacman should record what files are changed during install (from .install files), so it is possible to spot changed /etc files. For example the orphaned user gdm in /etc/passwd which I can imagine becoming a security risk at some point.

wonder · 2009-04-28 20:15:51

there is no security risk. gdm has default nologin

Wilco · 2009-04-29 07:20:27

But it goes against pacman philosophy (as I understand it).
I always thought that removing packages would leave the system in the exact same state as it was before installing. And that is no longer true with gdm

Cerebral · 2009-04-29 11:52:59

That's not the "pacman philosophy" - I don't know if there is a "pacman philosophy". What if you install a package, and run it, creating some configuration in your homedir? Pacman won't remove that either.

Wilco · 2009-04-29 13:20:38

But what if a "package install" also changes a system config file? The correct way to uninstall this would be to remove those entries from the config file or else you can never keep a clean system "without orphans".

If user intervention changes a config file user intervention should be required to revert the changes.
But if pacman decides to change a system file, pacman should also revert it.

Last edited by Wilco (2009-04-29 13:21:22)

nogoma · 2009-04-29 13:47:36

I think you'd have issues in the general case; I mean, if you installed, say, two web servers both of which run as user 'http'. Both of them will add a user 'http' if it doesn't already exist, but when you decide which one you prefer, you don't want the user removed when you uninstall the other one. Basically, if you want these sorts of reverts, you need to have some *further* dependency information for packages, i.e. "this package depends on user 'http' existing", so pacman would know when/if it can revert a change that multiple packages could potentially make.

Cerebral · 2009-04-29 14:25:44

Wilco wrote:

But what if a "package install" also changes a system config file? The correct way to uninstall this would be to remove those entries from the config file or else you can never keep a clean system "without orphans".

I don't know if there's a good general way to tell if the modification is caused by pacman or by a user.

How should pacman know if you want to keep the user or not in any of these scenarios:
What if a user adds the 'gdm' user to /etc/passwd, then installs gdm?
What if a user installs 'gdm', modifies the gdm user in some way, then uninstalls gdm?
What if (as nogoma said), two different packages would add the 'gdm' user, and you uninstall one of them?

It's making things more complex. The best solution, IMO, would be to have the package simply say "Hey, I added the gdm user, and you uninstalled me -- the gdm user is still there. Do whatever you want to it."

As a general rule, pacman packages modify very few system-wide configuration files - generally the most I've seen them do is add users or groups needed by the application, or update the font cache for example. When these modifications need to be made, the user should be informed, and from that point on it's up to the user to keep track of it.

venky80 · 2009-04-29 16:17:48

Cerebral wrote:

Wilco wrote:
But what if a "package install" also changes a system config file? The correct way to uninstall this would be to remove those entries from the config file or else you can never keep a clean system "without orphans".
I don't know if there's a good general way to tell if the modification is caused by pacman or by a user.
How should pacman know if you want to keep the user or not in any of these scenarios:
What if a user adds the 'gdm' user to /etc/passwd, then installs gdm?
What if a user installs 'gdm', modifies the gdm user in some way, then uninstalls gdm?
What if (as nogoma said), two different packages would add the 'gdm' user, and you uninstall one of them?
It's making things more complex. The best solution, IMO, would be to have the package simply say "Hey, I added the gdm user, and you uninstalled me -- the gdm user is still there. Do whatever you want to it."
As a general rule, pacman packages modify very few system-wide configuration files - generally the most I've seen them do is add users or groups needed by the application, or update the font cache for example. When these modifications need to be made, the user should be informed, and from that point on it's up to the user to keep track of it.

How should pacman know if you want to keep the user or not in any of these scenarios:
What if a user adds the 'gdm' user to /etc/passwd, then installs gdm?
By prompting the user that the file to be written during install by pacman already exists and by giving an option to purge the user created file by pacman.

What if a user installs 'gdm', modifies the gdm user in some way, then uninstalls gdm?
Again ask if during uninstall the config file should be reverted back to the "new system" or default state

What if (as nogoma said), two different packages would add the 'gdm' user, and you uninstall one of them?
How does pacman resolve dependency cant the same techniques used in this case, even if not why nt give an option to purge the file (knowing that it might screw the other package)

why not make a pacman group and make pacman owner of these files if there is a diff during uninstall from what the config looks as defaultprompt the user to decide..after the decision is made force that new file qwner as pacman so when it is uninstalled it can be cleaned up.

I am not much of an expert, but there should atleast be an option to remove the non home dir configs (such as in /etc)to be removed when a package is removed

I think reverting to original state without leaving cruft is a pretty popular request and i think it will make arch killer (it already is but still) I understand the complexities but it definitely seems like a very valid feature addition request

Cerebral · 2009-04-29 17:01:54

Most of your solutions boil down to "prompt the user", which is exactly what an output message on uninstall will do, without actually forcing the user intervention.

Xyne · 2009-04-29 17:32:33

Imo the best solution is to notify the user of changes that a package has made that will not be undone when removing the package. Upon uninstallation, these changes should be displayed so that the user can deal with them manually.

Wilco · 2009-04-29 19:04:45

Agreed with the last post. That would be easy, clean and is better than introducing all the overhead and so called pacman "intelligence". That would contradict the simple arch way.

Preferably after uninstalling 100+ Gnome packages I would like to see a message like:

/etc/passwd was modified during the installation of gdm, please compare /etc/passwd to /etc/passwd.pacoriginal
/etc/pam.d/su was modified during the installation of samba, please compare /etc/pam.d/su to /etc/pam.d/su.pacoriginal

I think we can all decide if we like these changes. At least now we know what has changed and we're back in control.

Teoulas · 2009-04-29 19:53:25

/etc/passwd was modified during the installation of gdm, please compare /etc/passwd to /etc/passwd.pacoriginal

What if there was another package that changed the /etc/passwd file after gdm was installed? Which version of .pacoriginal do we keep? Or do we keep multiple snapshots of the same "original" file? It's making things a bit too complex, I think. Just displaying any changes made upon uninstallation should be enough, like Xyne mentioned.

venky80 · 2009-04-29 20:13:31

Wilco wrote:

Agreed with the last post. That would be easy, clean and is better than introducing all the overhead and so called pacman "intelligence". That would contradict the simple arch way.
Preferably after uninstalling 100+ Gnome packages I would like to see a message like:
/etc/passwd was modified during the installation of gdm, please compare /etc/passwd to /etc/passwd.pacoriginal
/etc/pam.d/su was modified during the installation of samba, please compare /etc/pam.d/su to /etc/pam.d/su.pacoriginal
I think we can all decide if we like these changes. At least now we know what has changed and we're back in control.

Well I guess the difference between what I am suggesting to what others are saying is , I would like the user to make a decision when the package is being installed or uninstalled so that there is no option to ignore the logs generated by pacman.

Currently I can safely install uninstall without ever seeing the logs...more so if I am using a front end like shaman.

So maybe i just want the issue to be settled when installation and uninstall is being done.

I do not think that is too divergent from keep it simple stupid philosophy

Agreed with your post to not put more intelligence in pacman and make it complex..but force the user to clean the mess when it gets created.

Last edited by venky80 (2009-04-29 20:15:06)

Cerebral · 2009-04-29 22:40:35

venky80 wrote:

Currently I can safely install uninstall without ever seeing the logs...more so if I am using a front end like shaman.
So maybe i just want the issue to be settled when installation and uninstall is being done.
I do not think that is too divergent from keep it simple stupid philosophy
Agreed with your post to not put more intelligence in pacman and make it complex..but force the user to clean the mess when it gets created.

It may not diverge from the philosophy of simplicity, but it does diverge from our general approach of trusting the users to be able to handle these sorts of things themselves - Arch has never been a hand-holding distro, and forcing users to answer a bunch of Y/N questions when installing/uninstalling packages is somewhat of a hand-holding step when outputting a log (and trusting the user to read it) is sufficient.

venky80 · 2009-04-29 23:11:21

Cerebral wrote:

venky80 wrote:
Currently I can safely install uninstall without ever seeing the logs...more so if I am using a front end like shaman.
So maybe i just want the issue to be settled when installation and uninstall is being done.
I do not think that is too divergent from keep it simple stupid philosophy
Agreed with your post to not put more intelligence in pacman and make it complex..but force the user to clean the mess when it gets created.
It may not diverge from the philosophy of simplicity, but it does diverge from our general approach of trusting the users to be able to handle these sorts of things themselves - Arch has never been a hand-holding distro, and forcing users to answer a bunch of Y/N questions when installing/uninstalling packages is somewhat of a hand-holding step when outputting a log (and trusting the user to read it) is sufficient.

Well that seems really weird if the end goal is to have a clean system, how is making the user deal with the issue hand holding? but since we are talking apples and oranges there is not much to debate, I feel reverting back to original state is an important feature, for many others it isnt (not that few junk directories and files foating in the file system does any harm) so basically it is a debate about importance...and you know what pacman does ask a bunch of y and N questions when the result is deemed "important" so basically you think the feature is unimportant , I think it is important...so lets leave it there...

Anyway for a user like me, (not an expert here) maybe getting to decide during the point of change might actually make me more aware, coz I think I have been using Arch for some years happily yet I do not think i have the necessary "expertise" in cleaning my system.

Last edited by venky80 (2009-04-29 23:16:00)

Cerebral · 2009-04-30 13:10:01

venky80 wrote:

and you know what pacman does ask a bunch of y and N questions when the result is deemed "important" so basically you think the feature is unimportant

Pacman asks questions at the start of the procedure - once the actual update process starts, pacman doesn't ask any more questions (which IMO is really nice - you can start a large update and walk away, checking the logs when you return).

venky80 · 2009-04-30 14:28:24

Cerebral wrote:

venky80 wrote:
and you know what pacman does ask a bunch of y and N questions when the result is deemed "important" so basically you think the feature is unimportant
Pacman asks questions at the start of the procedure - once the actual update process starts, pacman doesn't ask any more questions (which IMO is really nice - you can start a large update and walk away, checking the logs when you return).

Again for large updates if the concern is Qs at the middle then you could specify a default answer as to what you want to do when a conflict occurs, or update the packages and at the end wait for user to return and specify what to do with the conflicting files.
As I said reverting to original state might not be a priority for devs currently but if it were the "Arch philosophy" is flexible enough, you could trivialize by saying hand holding, but I say it forces users to learn in terms of what happened to the system.
As it is user can currently safely ignore these logs, which eventually leads to a system which cannot ever go back to a fresh install state.

Cerebral · 2009-04-30 15:34:41

Since you feel this strongly about it, I suggest you open a feature request on FlySpray: http://bugs.archlinux.org/

venky80 · 2009-04-30 17:56:38

Cerebral wrote:

Since you feel this strongly about it, I suggest you open a feature request on FlySpray: http://bugs.archlinux.org/

It is already there..;)
Thanks
http://bugs.archlinux.org/task/13998?pr … pened=4190

Arch Linux

#1 2009-04-28 18:42:41

Pacman really made a mess of my system this time :(

#2 2009-04-28 18:47:53

Re: Pacman really made a mess of my system this time :(

#3 2009-04-28 19:00:56

Re: Pacman really made a mess of my system this time :(

#4 2009-04-28 19:11:35

Re: Pacman really made a mess of my system this time :(

#5 2009-04-28 19:21:48

Re: Pacman really made a mess of my system this time :(

#6 2009-04-28 19:33:57

Re: Pacman really made a mess of my system this time :(

#7 2009-04-28 19:52:58

Re: Pacman really made a mess of my system this time :(

#8 2009-04-28 20:15:51

Re: Pacman really made a mess of my system this time :(

#9 2009-04-29 07:20:27

Re: Pacman really made a mess of my system this time :(

#10 2009-04-29 11:52:59

Re: Pacman really made a mess of my system this time :(

#11 2009-04-29 13:20:38

Re: Pacman really made a mess of my system this time :(

#12 2009-04-29 13:47:36

Re: Pacman really made a mess of my system this time :(

#13 2009-04-29 14:25:44

Re: Pacman really made a mess of my system this time :(

#14 2009-04-29 16:17:48

Re: Pacman really made a mess of my system this time :(

#15 2009-04-29 17:01:54

Re: Pacman really made a mess of my system this time :(

#16 2009-04-29 17:32:33

Re: Pacman really made a mess of my system this time :(

#17 2009-04-29 19:04:45

Re: Pacman really made a mess of my system this time :(

#18 2009-04-29 19:53:25

Re: Pacman really made a mess of my system this time :(

#19 2009-04-29 20:13:31

Re: Pacman really made a mess of my system this time :(

#20 2009-04-29 22:40:35

Re: Pacman really made a mess of my system this time :(

#21 2009-04-29 23:11:21

Re: Pacman really made a mess of my system this time :(

#22 2009-04-30 13:10:01

Re: Pacman really made a mess of my system this time :(

#23 2009-04-30 14:28:24

Re: Pacman really made a mess of my system this time :(

#24 2009-04-30 15:34:41

Re: Pacman really made a mess of my system this time :(

#25 2009-04-30 17:56:38

Re: Pacman really made a mess of my system this time :(

Board footer