FS#66017 - proposal on how to safely replace unowned files

Attached to Project: Pacman
Opened by Fabian (Tids) - Sunday, 29 March 2020, 16:04 GMT
Last edited by Allan McRae (Allan) - Sunday, 29 March 2020, 23:08 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Proposal of a feature.

Hi. Because I, and the Arch project itself hits this limitation of pacman often enough. I wanted to write a proposal on how to handle this. Sadly I'm not a programmer and cant write the code for it myself. Sorry for this! The next best thing is to write how I (in fact "we") imagine how it would work out the best way.


supersedefile=()
Array of (full) paths of files the package wants to replace

How it should work:
To work 3 conditions needs to be fulfilled.
1. the PKGBUILD needs to have a full path set in the 'supersedefile' array
2. the package, needs to have a real file in place for every file path set in 'supersedefile'
3. the path needs to be an >not< owned file (no belonging to any package)

Condition 1: Set to be sure that a file will not conflict with, but replace a file on the FS. The default behavior to conflict is a good default and should stay that way.

Condition 2: Because we need to be sure that the path that is set, will also be used by the package and is not some kind of placeholder. It will also verify, that the new file belongs to the package.

Condition 3: To make is safe, that the file it replaces is not part of another package, as well as not part of its own package in an earlier version, that could overwrite a users change.


Examples where this feature is useful:
* most times of packaging errors where your users have to use --overwrite
* https://www.archlinux.org/news/firewalld081-2-update-requires-manual-intervention/
* https://www.archlinux.org/news/hplip-3203-2-update-requires-manual-intervention/

* For a software that was creating its default config on 1st start to /etc, but because of the move to wayland and the removal of writing to /etc (because no root anymore) now requires that the default config is shipped by the package and there is no straight forward feature to replace a file and make the package its new owner without any hacky move. <- That's the one I face rn
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 29 March 2020, 23:08 GMT
Reason for closing:  Won't implement
Comment by Andrew Gregory (andrewgregory) - Sunday, 29 March 2020, 20:54 GMT
I'd prefer people just use --overwrite. We have no way of knowing if the packaged application actually put the file there or if it's a user file that shouldn't be overwritten. --overwrite allows the user to verify that the unowned file is actually something that should be replaced.
Comment by Allan McRae (Allan) - Sunday, 29 March 2020, 23:08 GMT
Agreed. I want the user to make the decision of which files to overwrite, not the packager.

Loading...