[aur-general] Question file conflict on a new package I took over
I just recently took over a package[1], and some people are having troubles updating due to file system conflict. error: failed to commit transaction (conflicting files) uuid: /usr/lib/libuuid.a exists in filesystem uuid: /usr/lib/libuuid.so exists in filesystem uuid: /usr/lib/pkgconfig/uuid.pc exists in filesystem uuid: /usr/share/man/man3/uuid.3.gz exists in filesystem Errors occurred, no packages were upgraded. 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. Would the correct way be to use a .install file and then a pre_install hook to get rid of them? Thanks a bunch for any help or tips here. [1]uuid <https://aur.archlinux.org/packages/uuid/>
On Mon, Dec 10, 2012 at 7:46 PM, Don deJuan <donjuansjiz@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. -- Gianni Vialetto "To see things in the seed, that is genius." - Lao Tzu
Gianni Vialetto wrote:
On Mon, Dec 10, 2012 at 7:46 PM, Don deJuan <donjuansjiz@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
On 12/11/2012 02:32 PM, Xyne wrote:
Gianni Vialetto wrote:
On Mon, Dec 10, 2012 at 7:46 PM, Don deJuan <donjuansjiz@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. :)
participants (3)
-
Don deJuan
-
Gianni Vialetto
-
Xyne