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

[Don deJuan]

On 12/11/2012 02:32 PM, Xyne wrote:
> 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
>
Thanks guys I have not done what I asked about. And learned a bunch from 
your input. Thank you all for your time. I believe this was all caused 
by me missing the commenting of a patch.. Everyone said was fixed after 
removing the comment ... *embarassed* .. But this info was great to get 
in any case. :)