[pacman-dev] [feature request] ignore certain file conflicts
Hi pacman devs, Sometimes it happens that a user has to force an upgrade because pacman detects an file conflict. Some of those cases are caused by the known link vs. regular file/directory problem. Others are caused by the fact that a file wasn't tracked by pacman before. (e.g. something that was created by an install script before and is part of the package itself now) I am not sure if the first case can even be fixed at all. So what about an variable I could define in the PKGBUILD which would handle this? overwrite=('usr/lib/somefile' 'usr/lib/someotherfile') I am not sure if this is completly insane and how difficult to implement this mgiht be. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
On Mon, Mar 2, 2009 at 4:54 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
The concept is a decent idea, but we'd really have to make sure it's used sparingly. I could forsee this overtaking "conflicts" with AUR packages. Perhaps if this just prompted the user? foobar-1.0-2 wants to overwrite /usr/lib/zomg.so. Allow? [y/N]
Aaron Griffin wrote:
foobar-1.0-2 wants to overwrite /usr/lib/zomg.so _which is not tracked by pacman_. Allow? [y/N] Otherwise, this is interesting. A bug report would be good so we keep track of this. Allan
On Mon, Mar 2, 2009 at 11:49 AM, Allan McRae <allan@archlinux.org> wrote:
Redux: /usr/lib/zomg.so is not owned by any package. Allow foobar-1.0-2 to overwrite this file? [y/N] Optional: s/overwrite/claim ownership of/
In this case we don't need overwrite option at all, right? (This can be detected automatically. However, this detection is slow.)
Nagy Gabor wrote:
I had just thought the same thing but why would it be so slow? Would the conflict checking not already find the conflict with an unowned file on the system and so this is just adding a query? Allan
On Mon, Mar 2, 2009 at 2:33 PM, Allan McRae <allan@archlinux.org> wrote:
I don't think we'd want to do this automatically. What if I actually installed something via "make install" and don't want it overwritten? Or perhaps I want a chance to C-c the operation to fiddle with these overwrite files...
I didn't say that I vote to keep confirmation question and then you can answer no. By the way, it can be always useful (but slow) to query fileowners. In case of fileconflict, we just get an error message "/usr/bin/foo exists in filesystem", so pacman doesn't inform us about (file)conflicting packages ("local package foo conflict with transaction package foo-ng"). Bye
On Mon, Mar 2, 2009 at 10:01 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
+1 1) The first recommended thing to do in this case is pacman -Qo /usr/bin/foo anyway 2) I always found this message odd, it sounds like pacman does not know that file, while it could very well have tracked it and know which package it belongs to 3) This is an error case, it doesn't have to be lightning fast, it should rather be as informative as possible
On Mon, Mar 2, 2009 at 11:54 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
In the case of a symlink directory problem, we could have many file conflicts, it would seem quite ugly to have to overwrite all the files inside. IIRC, Nagy had several ideas about possible fixes for these problems (or maybe not all problems, but at least some of them). And if we are going to put some effort on something related to file conflicts, it would make more sense to try to fix/improve this code rather than providing a workaround. But if there is no one to put some effort to start with, then we don't have any problems for figuring out what should be done :) Of course, there are also the cases where the conflict is real and a file wasn't tracked by pacman. So I am not sure either.
participants (5)
-
Aaron Griffin
-
Allan McRae
-
Nagy Gabor
-
Pierre Schmitz
-
Xavier