During emerge of sys-fs/udev-182 I get the following error: * Detected file collision(s): * * /usr/share/gtk-doc/html/gudev * /usr/share/gtk-doc/html/libudev * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * sys-fs/udev-182 * /usr/share/gtk-doc/html/gudev * /usr/share/gtk-doc/html/libudev * * Package 'sys-fs/udev-182' NOT merged due to file collisions. If * necessary, refer to your elog messages for the whole content of the * above message. So it has file colisions with itself? I'm using Portage 2.2.0_alpha93. I'll post full --info if you want it.
I can confirm this problem, same error message, same effect on my machine here.
Same here, sys-fs/udev-182 collides with sys-fs/udev-171-r5.
I confirm this too with same error message. Removing colliding directories and reemerging udev solves the issue.
Here is the error Maxim Koltsov encountered: http://paste.pocoo.org/show/569827/ It is slightly different than the one Tim Ryan posted. In Maxim Koltsov's case, udev is colliding with the older version, sys-fs/udev-171-r5. This should be handled with portage. As per a chat with Maxim Koltsov in #gentoo-dev, I am reassigning this bug to the portage team.
These two things are really strange: 1) sys-fs/udev-182 collides with itself, which is supposed to be impossible 2) /usr/share/gtk-doc/html/gudev and /usr/share/gtk-doc/html/libudev are supposed to be directories, and collsions between directories are supposed to be impossible
What's happening is that the ebuild is trying to replace directories with symlinks, which is explicitly banned by PMS section 13.4 where it says "Ebuilds must not attempt to merge a symlink on top of a directory". This bit of portage code from bug 326685 enforces it: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a4a4d87786e6c0c34370870af2071904d6184a9d It looks like portage needs to produce a better error message here, at least.
(In reply to comment #6) > What's happening is that the ebuild is trying to replace directories with > symlinks, which is explicitly banned by PMS section 13.4 where it says > "Ebuilds must not attempt to merge a symlink on top of a directory". > > This bit of portage code from bug 326685 enforces it: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=a4a4d87786e6c0c34370870af2071904d6184a9d > > It looks like portage needs to produce a better error message here, at least. I need to replace them with symlinks since the documentation was moved to different directory and the symlinks provide backwards compability link for devhelp. So *how* do you replace dirs with symlinks in a way it works? I'll be needing this with hundreds of packages soon as I've figured out proper gtk-doc.eclass automating this for other packages as well.
(In reply to comment #7) > So *how* do you replace dirs with symlinks in a way it works? I guess the closes fit to PMS section 13.4 would be to use a hard blocker, so that the user has to unmerge the directory before installing the version that has the symlink. I'll CC pms-bugs in case anybody else wants to comment.
You could also create the symlink in pkg_postinst, which will execute after the directory has been unmerged.
This will fix the error message to clarify exactly why it aborts: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7c58705c30fed6b11f978c4880225ced8a45c70d
I'm testing the advice in comment #9. That works, but it also means that the symlinks are not owned by the package. I'm not sure this is a good idea.
It looks like a rev bump of udev might fix the issue, so I'll try that approach.
(In reply to comment #11) > I'm testing the advice in comment #9. > That works, but it also means that the symlinks are not owned by the > package. I'd rather do the necessary cleanup (removing the directory of the old package) and create the symlink in pkg_preinst. The symlink will belong to the new package then.
(In reply to comment #13) > (In reply to comment #11) > > I'm testing the advice in comment #9. > > That works, but it also means that the symlinks are not owned by the > > package. > > I'd rather do the necessary cleanup (removing the directory of the old > package) and create the symlink in pkg_preinst. Sounds good (assuming it works :-) > The symlink will belong to the new package then. Which seems pretty important so we don't have to leave orphans behind.
Please try upgrading to udev-182-r1 and see if that happens successfully. Please let us know here on the bug.
Yeah, creating symlinks in pkg_preinst should work fine. (In reply to comment #10) > This will fix the error message to clarify exactly why it aborts: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=7c58705c30fed6b11f978c4880225ced8a45c70d This is in portage-2.1.10.51 and 2.2.0_alpha95. Re-assigning to udev-bugs to resolve the collision.
portage version: sys-apps/portage-2.1.10.51 >>> Installing (1 of 1) sys-fs/udev-182-r1 * Package 'sys-fs/udev-182-r1' has one or more collisions between * symlinks and directories, which is explicitly forbidden by PMS section * 13.4 (see bug #326685): * * /usr/share/gtk-doc/html/libudev * /usr/share/gtk-doc/html/gudev
I forgot to say that with portage-2.1.10.51 and udev-182 everything is OK
sorry withh portage-2.1.10.50 everything is OK. Portage 2.1.10.51 and udev-182 the same error occurs
(In reply to comment #13) > (In reply to comment #11) > > I'm testing the advice in comment #9. > > That works, but it also means that the symlinks are not owned by the > > package. > > I'd rather do the necessary cleanup (removing the directory of the old > package) and create the symlink in pkg_preinst. The symlink will belong to > the new package then. Won't work; if it does, then that's a bug and reversal of long term behaviour. collision-protect runs prior to preinst; it has to- the point is to do the sanity check w/out modifying the FS. preinst by definition can do whatever the hell it wants, thus collision-protect scans have always occurred *prior* to preinst.
(In reply to comment #19) > sorry withh portage-2.1.10.50 everything is OK. > Portage 2.1.10.51 and udev-182 the same error occurs The only difference between portage-2.1.10.50 and 2.1.10.51 is that the error message is more informative. You're probably confused by changes to the udev ebuild which occurred without a revision bump. (In reply to comment #20) > (In reply to comment #13) > > I'd rather do the necessary cleanup (removing the directory of the old > > package) and create the symlink in pkg_preinst. The symlink will belong to > > the new package then. > > Won't work; if it does, then that's a bug and reversal of long term > behaviour. > > collision-protect runs prior to preinst; it has to- the point is to do the > sanity check w/out modifying the FS. preinst by definition can do whatever > the hell it wants, thus collision-protect scans have always occurred *prior* > to preinst. It will work as long as the symlinks are created in $D during pkg_preinst rather than src_install. That way, the symlinks won't exist when the collision protect phase runs before pkg_preinst.
Ok, now I believe I have the fix in udev-182-r1. Please try agaiafter the top of the hour (0100 utc) and let me know if you can install udev-182-r1. Thanks, William
(In reply to comment #21) > (In reply to comment #20) > > Won't work; if it does, then that's a bug and reversal of long term > > behaviour. > > > > collision-protect runs prior to preinst; it has to- the point is to do the > > sanity check w/out modifying the FS. preinst by definition can do whatever > > the hell it wants, thus collision-protect scans have always occurred *prior* > > to preinst. > > It will work as long as the symlinks are created in $D during pkg_preinst > rather than src_install. That way, the symlinks won't exist when the > collision protect phase runs before pkg_preinst. Do I need to quote the definitions of kludges and hacks? Cause this fits. If you want to exempt something from a collision protection failure, add a far of what should be ignored; don't do shit like this (it just makes everyone elses life hell later one when we have to emulate/hack around it).
(In reply to comment #23) > If you want to exempt something from a collision protection failure, add a > far of what should be ignored; *Add a var. Christ I fail at english :/
(In reply to comment #23) > (In reply to comment #21) > > (In reply to comment #20) > > > Won't work; if it does, then that's a bug and reversal of long term > > > behaviour. > > > > > > collision-protect runs prior to preinst; it has to- the point is to do the > > > sanity check w/out modifying the FS. preinst by definition can do whatever > > > the hell it wants, thus collision-protect scans have always occurred *prior* > > > to preinst. > > > > It will work as long as the symlinks are created in $D during pkg_preinst > > rather than src_install. That way, the symlinks won't exist when the > > collision protect phase runs before pkg_preinst. > > Do I need to quote the definitions of kludges and hacks? Cause this fits. > > If you want to exempt something from a collision protection failure, add a > far of what should be ignored; don't do shit like this (it just makes > everyone elses life hell later one when we have to emulate/hack around it). Since the exception variable would allow a package to override something that is specifically forbidden by PMS, wouldn't that require an EAPI bump?
(In reply to comment #25) > (In reply to comment #23) > > (In reply to comment #21) > > > (In reply to comment #20) > > > > Won't work; if it does, then that's a bug and reversal of long term > > > > behaviour. > > > > > > > > collision-protect runs prior to preinst; it has to- the point is to do the > > > > sanity check w/out modifying the FS. preinst by definition can do whatever > > > > the hell it wants, thus collision-protect scans have always occurred *prior* > > > > to preinst. > > > > > > It will work as long as the symlinks are created in $D during pkg_preinst > > > rather than src_install. That way, the symlinks won't exist when the > > > collision protect phase runs before pkg_preinst. > > > > Do I need to quote the definitions of kludges and hacks? Cause this fits. > > > > If you want to exempt something from a collision protection failure, add a > > far of what should be ignored; don't do shit like this (it just makes > > everyone elses life hell later one when we have to emulate/hack around it). > > Since the exception variable would allow a package to override something > that is specifically forbidden by PMS, wouldn't that require an EAPI bump? Pretty sure you answered your own question...
(In reply to comment #23) > Do I need to quote the definitions of kludges and hacks? Cause this fits. Why? The whole purpose of pkg_preinst is that such special cases can be handled. > If you want to exempt something from a collision protection failure, add a > var of what should be ignored; don't do shit like this (it just makes > everyone elses life hell later one when we have to emulate/hack around it). How would a variable help here? You'd still have to remove the old directory at some point, either in pkg_setup (dangerous if the build of the new package fails) or in pkg_preinst.
(In reply to comment #27) > (In reply to comment #23) > > Do I need to quote the definitions of kludges and hacks? Cause this fits. > > Why? The whole purpose of pkg_preinst is that such special cases can be > handled. What if some other PM does collision checking before pkg_preinst()? It's allowed to do so. > > If you want to exempt something from a collision protection failure, add a > > var of what should be ignored; don't do shit like this (it just makes > > everyone elses life hell later one when we have to emulate/hack around it). > > How would a variable help here? You'd still have to remove the old directory > at some point, either in pkg_setup (dangerous if the build of the new > package fails) or in pkg_preinst. Install can fail as well. And with that hack, even with rollback feature it will be a horrible failure. As long as we're limited by current PMS, there's no good way of doing that.
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #23) > > > Do I need to quote the definitions of kludges and hacks? Cause this fits. > > > > Why? The whole purpose of pkg_preinst is that such special cases can be > > handled. > > What if some other PM does collision checking before pkg_preinst()? It's > allowed to do so. The collision checking is already done before pkg_preinst, and it works fine. See my explanation at the end of comment #21. The key thing to note is that the symlinks must be created in pkg_preinst rather than src_install, and the colliding directories must be removed in pkg_preinst.
The Update from udev-182 to udev-182-r2 works now fine :) Thank you
With portage-2.2.0_alpha95 udev-182-r2 updates without any errors. Thanks.
The more I think about this, I tend to agree with Ulrich in comment #27; this is a special case. We are moving package-specific directories from one location to another then linking to them from the original location, so nothing is lost just rearranged. Given that, Zac's explanation in comment #21 and comment #29 And users saying that udev-182-r2 upgraded successfully in comment #30 and comment #31, I am closing this bug. If anyone disagrees, feel free to reopen.
