On Mon, Mar 2, 2009 at 11:49 AM, Allan McRae <[email protected]> wrote: > Aaron Griffin wrote: >> >> On Mon, Mar 2, 2009 at 4:54 AM, Pierre Schmitz <[email protected]> >> wrote: >> >>> >>> 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. >>> >> >> 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] >> > > 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.
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/ _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
