On 12/11/2012 02:32 PM, Xyne wrote:
Gianni Vialetto wrote:
On Mon, Dec 10, 2012 at 7:46 PM, Don deJuan <[email protected]> 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. :)
