FS#38396 - conflict/dependency ignore switch dysfunctional resulting in broken system
Attached to Project:
Pacman
Opened by Mathias Steiger (mathiassteiger) - Monday, 06 January 2014, 15:10 GMT
Last edited by Allan McRae (Allan) - Monday, 06 January 2014, 15:26 GMT
Opened by Mathias Steiger (mathiassteiger) - Monday, 06 January 2014, 15:10 GMT
Last edited by Allan McRae (Allan) - Monday, 06 January 2014, 15:26 GMT
|
Details
Summary and Info:
Sdd, nodeps, force or whatever weird combination required, as of recent, should ignore conflicts and dependencies. If conflicts are exempt (by god why?), there must be a way to ignore conflicts. Even better, there should be means to ignore specific conflicting packages either all the time or at least somehow. Man page: "--nodeps Skips dependency version checks. Package names are still checked. Normally, pacman will always check a package’s dependency fields to ensure that all dependencies are installed and there are no package conflicts in the system. Specify this option twice to skip all dependency checks. " Steps to Reproduce: 1. Install Archlinux 2. Wait for some random update constellation that occurs all the time somehow since the advent of Archlinux and doesn't turn out to work 3. End up with a cascading mess of package removals and nodeps-force installations, just to get around this bug, and hope that it doesn't involve removing coreutils or anything crucial 
what_happens_if_you_cant_igno...
(3.1 KiB)
|
This task depends upon
pacman -Sddddddd --nodeps --nodeps --force --ignore xorg-server --ignoregroup xorg-server xf86-input-evdev
What your problem boils down to is the nvidia dirvier does not work with the new xorg. But for some reason you want to ignore the strong hint provided by the conflict and upgrade xorg-server anyway. While ignoring xorg-server? Seriously, WTF do you expect this to do:
pacman -Sddddddd --nodeps --nodeps --force --ignore xorg-server --ignoregroup xorg-server xorg-server
Remove the Arch [testing] repository from you pacman.conf. Do a "pacman -Syuu".
1. If the new nvidia-utils doesn't work with the xorg-server from the testing repository, and I answer that I don't want to remove it, pacman should naturally pull the appropriate xorg-server package version that works instead of blocking the whole process. Anything else doesn't make much sense in the end. Now I will probably be removing the testing repository, install xorg-server, then add it again. Or in other words: manually emulate that behavior.
2. If you looked through the chain of commands, you notice that I had to nodeps-force-remove xorg-server, just to install xf86-input-evdev and then reinstall xorg-server again! This kind of (effectively) nonsensical and often circular package blocking occurs all the time and is what I am talking about here. In the past (many many years ago), it actually went down to pacman requiring you to remove coreutils (if you didn't do some tricks with ignore switches) before you could reinstall everything with a boot CD. This ridiculousness had also been frequent on Gentoo and was one of the main reasons that portage failed at each and every update process. Don't know if they fixed it in the last years.
3. Iirc, -Rd first became -Rdd, then -Rdd ceased working and only --nodeps worked. Something similar happened to the -f switch for all I know. But you might imagine that I don't obsessively read the pacman Changelog every other day. So I don't really know how much worse that command got in the last year. I am annoyed and I exaggerated on the absurdity of it.
4. Often package conflicts are overly restrictive and unnecessary for the purpose. The best example is, that you can in fact install xf86-video-intel in parallel with nvidia drivers and it works _flawlessly_ without intel DRI. But because intel-dri is a dependency of xf86-video-intel, it is blocked by pacman. There is no way to ignore that conflict in an update process, you have to manually remove and install it with each update. I already reported this and it also was ignored.
Bottom line is: pacman is just a tool, I am a human being and if I wanted to install something I should be allowed to because I always win on intelligent decision capabilities. A tool should do what you want it to do and not hog your time because it imposes restrictions which you can look far beyond. If it doesn't work, I will just do something else.
Just look at the chain of commands and how necessary it all was.
Pacman is a great package manager, I love Archlinux, but this is just annoying. And it is annoying in that aspect without any reason other than questioning the intelligence of the user. If you think it thought at least.
Maybe you should be correct rather than blunt.
What is that even supposed to mean? I demonstrated the case and I didn't make this stuff up or whatever you seem to be implying here.
Point #2: In this case, just one package. But nonetheless true. The block was effectively nonsensical, just look at the log.
Point #1: You could call that essentially the root of the whole problem and I realize it isn't a bug but a missing feature.
Point #3: I have no clue about the history of those command changes, all I know is that -d would ignore dependencies, -f would force, just what you naturally expect it to do. And then it didn't. I don't know the reasons it was changed, and I don't really care. Neither is it my hobby to read and meticulously interpret manpages, changelogs and source code all day.
Point #4: Absolutely true.
Supposing, that I wanted to remove (=downgrade) all the testing packages. Which I don't.
Why does it block, instead of automatically pulling the appropriate version?
I can't imagine that that is so hard to implement.
Just to note on that ... It would have done everything for me if:
1. I knew each and every package version and which repository it came from on my PC off the top of my head
2. I looked up and memorized all the package conflicts in advance, before I executed any commands
Otherwise, you end up with the command schema you see in the log, which is just the basic trial and error approach and the quickest way to get anywhere.