[aur-general] Question file conflict on a new package I took over

[Xyne]

Gianni Vialetto wrote:

>On Mon, Dec 10, 2012 at 7:46 PM, Don deJuan <donjuansjiz at gmail.com> wrote:
>> I just recently took over a package[1], and some people are having troubles
>> updating due to file system conflict.
>
>It seems that the util-linux package already contains a (different) libuuid.
>
>> What is the actual proper way to handle a conflict like this? As a temp
>> workaround I found that if I removed the package and then deleted those
>> files left behind I can get it to install and all seems kosher after. But
>> that is a ugly workaround.
>
>Really ugly - in fact this workaround breaks util-linux and even
>e2fsprogs (fsck.ext*) functionality, ouch.
>As things stands i believe there is no easy solution to your problem -
>renaming the library to something else seems to me the only way to
>escape this DLL naming madness.
>
>> Would the correct way be to use a .install file and then a pre_install hook
>> to get rid of them?
>
>Absolutely not. This could (and as murphy's law dictates, will) mess
>up with the state of the system.
>Event if you're sure it will not corrupt your file system or burn your
>CPU - and in the world of DLL no one is - i believe it's bad pratice
>in general to touch files other than those "owned" by your package in
>the .install file hooks.


NEVER remove existing files from other packages with install scripts. This is
such a bad idea that I cannot stress this point strongly enough. You can
cause the user to lose data or break the system to the point of needing a
live CD to fix it. Such a package will be considered malicious and deleted on
sight.

When file conflicts arise, there are several cases to consider:

1) The existing file belongs to another package and your package provides
similar functionality. In this case, add appropriate entries to the "conflicts"
and "provides" arrays in the PKGBUILD.

2) The existing file belongs to another package but the name is purely
coincidental, i.e. the file provided by your package has nothing to do with the
existing file. In this case, if one package is clearly more common/important
than the other, then that package maintains the name and the other should
change the name, ideally by requesting a change upstream to avoid the conflict.
You can add the other package to the "conflicts" array but obviously not to the
"provides" array.

3) The existing file does not belong to a package but it is generated/used by a
packaged application (e.g. a configuration file). This should be handled
similar to case 2.

4) The existing file is something that user has created, independent of a
package (i.e. something specific to a given user's system and not common). In
this case I would recommend doing nothing. The user can deal with the conflict
him- or herself.

If multiple users complain about conflicts then you are dealing with one of the
first 3 cases. Use "pacman -Qo /path/to/file" to determine which package, if
any, owns the file and proceed accordingly.

Regards,
Xyne