FS#28377 - Option to keep existing files and install package

Attached to Project: Pacman
Opened by ifiknew (ifiknew) - Sunday, 12 February 2012, 13:48 GMT
Last edited by Dan McGee (toofishes) - Sunday, 12 February 2012, 23:47 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

As oposoed to the --force option that installs the package and overwrites the existing files; a option that would install the package but keep the existing files with the same name/location as the ones in the package. If possible, it should exclude the already existing files from the list of the files owned by that package, as the user should be responsible for the files he manually put there.
It could be useful if someone, for example, has modified shared libs that he doesn't want to be overwritten.
Thanks.
This task depends upon

Closed by  Dan McGee (toofishes)
Sunday, 12 February 2012, 23:47 GMT
Reason for closing:  Won't fix
Additional comments about closing:  See comments.
Comment by Dan McGee (toofishes) - Sunday, 12 February 2012, 21:30 GMT
If you really want to hose your system this bad, it sounds like --dbonly is what you are looking for.
Comment by Allan McRae (Allan) - Sunday, 12 February 2012, 22:41 GMT
I say "Won't Fix"... this is the opposite of package management. If you have a custom version of a library, provide a new package for it.
Comment by ifiknew (ifiknew) - Monday, 13 February 2012, 18:16 GMT
Not really Dan. Possibly i wasn't all that clear above. What i meant was: a option that would install the package and the files from it but not overwrite any existing files that match the ones in the package, and because they aren't really the files from the package do not list them as being owned by the package.
Allan, i don't really see how this is the opposite of package management, i would rather call it splitting the package(s) to achieve even grater modularity. As for the new package, fair enough, but with reinstalling the original package without the modified shared libs i would again overwrite the modified shared libs - which this report was about preventing.
Here's a scenario that would maybe fit better in your package management standards:
You have a installed package(pkg1) and another package(pkg2) that has modified version of a lib that pkg1 provides, now if you reinstall pkg1 it would overwrite the modified shared lib from pkg2 and you would need to install pkg2 again.
Another thought maybe? Thanks and sorry for the inconvenience.
Comment by Dan McGee (toofishes) - Monday, 13 February 2012, 18:20 GMT
pacman is short for PACkage MANagement. You are asking for file management and expecting different packages (and things that are not packages at all) to claim ownership, which is not what we do. We will not be implementing this, ever, as there are much more sane ways of doing what you want that involve actually packaging proper packages with conflicts/replaces, among other solutions.
Comment by ifiknew (ifiknew) - Monday, 13 February 2012, 23:07 GMT
Yes i'm aware of that. Umm ok... Again sorry for the inconvenience and thanks.

Loading...