You are not logged in.
Well this questions is one I have a bit longer but never asked. I can remember there was one package (vim: http://www.archlinux.org/news/445/) I used and an upgrade needed me to manually delete some files.
And now again there's this news: "Cups update requires user interaction" on the mainsite telling people, it could be they need to manually change files.
And the question is: does the update really require the user interaction or does the cups package just need a better pre-install script?
Why not check if the file exists and if yes, let's do what we always do: keep the old ones and give the newones a .pacnew extension. What's wrong with this solution? I also asked this question to myself with the vim-upgrade. Why didn't the install script do this work for me but every single archuser out there has to do it by himself?
I mean, k that are no big things the users have to do but in generally it would be good to take care of such things automatically if it's possible and at least from my point of view, a good install-script can do anything the user can do. I mean it's a shell-script running with root-rights...
Offline
Not really sure about this, but I think that it's because those files weren't installed by pacman, but created on runtime. Pacman checks the files in the backup array in case they have been user-modified, but if it didn't know of those files (pacman didn't know the md5 of the original file) that can't be done.
Offline
Yes, but that doesn't answer the question why this part isn't done with a pre-install script.
Offline
Since the new conflicting files are 0-byte, that should have been possible to do in a better way. Maybe it's not the packager's fault, but pacman. Anyway, I consider that a bug.
Offline
One of you post a bug report then.
Offline
It will not be considered a bug... those files were added to the package so pacman will track them and remove them when you uninstall cups. pre_install should not be used to touch files on a persons system.
Offline
pre_install should not be used to touch files on a persons system.
Why not?
Any better solution to make archlinux stop requiering manual intervention when updating packages or are you all fine with the status quo? I mean also if it's not the perfect solution it would be a workaround we could use at the moment until someone comes up with a better idea.
Last edited by Rorschach (2010-03-26 11:52:40)
Offline
pre_install should not be used to touch files on a persons system.
Why not?
The file is not controlled by pacman so pacman should not touch it.
Offline
Right, that's the reason why I suggested pacman doesn't touch it but copies the new one with a .pacnew extension.
Offline
But how would it distinguish a conflict where it is OK to install a file with a .pacnew extension from a genuine conflict where doing so would be bad.
Offline
I think that depends on the case. The news about cups and vim aren't telling much about how these conflicts appeared. At least with vim it looks as every user had been effected while the news about cups just say some.
Now let's pretend those cups files are user genereated config-files and now cups ships them automatically as empty files. We have a conflict pacman doesn't handle because he doesn't now about these files before. That's the problem here, isn't it? When the user created these config-files I think it's pretty safe to assume he wants to keep them (why else should he have created them before?). Thus we can say in this case it's safe to keep the old ones and add the new ones with a .pacnew extension.
Offline
OK... let say I have a library I created called "libfoo" and it is critical for my system but not managed by pacman. Then glibc adds a libfoo and it is super important and pacman notices a conflict when trying to upgrade. In this case it would be really bad to install something as a .pacnew. How is pacman meant to distinguish between this case and the "harmless" cups case? It is always best to lean on the "do not screw up a users system" side of things.
Offline
I totally agree to your libfoo example! And maybe we can't/shouldn't handle this automatically by pacman at all. But as said, it depends on the case. The cups package could have moved the original files to *.tmp in pre_install and after pacman installed the new ones, exchange them and give the newones a .pacnew extension in post_install. I think this would satisfy the "do not screw up a users system" because you leave it as the user expects it. If I create a custom config-file for application XY, I don't expect pacman to do something with this config file when upgrading the package. In this cups-case pacman wants to replace them with empty-files (which is not what users want) and alerts a conflict.
Offline
I think you are missing a major issue here... pre_install/pre_upgrade runs after the conflict checking.
Offline
Ohh you are right I was really missing this....at the moment I can't think of a solution for this. Maybe someone else has an idea?
Offline
what's you problem with user interaction? i mean we are Arch ![]()
Offline
The problem with user interaction is that you don't know you need it until you try upgrading and it fails for some obscure reason that you end up searching the website for an explanation of. Rather than just failing pacman should be able to say "User intervention required for upgrading the following package: please refer to ..."
Offline