There is a file collision between the mentioned packages. The symlink /usr/share/cups/model/foomatic-ppds is owned by both packages, but they do not block eachother. With FEATURES="collision-protect" this is fatal. Reproducible: Always Steps to Reproduce: 1. emerge one of hplip or foomatic-filters-ppds 3. try to emerge the other Actual Results: >>> Completed installing hplip-1.7.3 into /mnt/mutable/portage_local/builddir/portage/net-print/hplip-1.7.3/image/ strip: x86_64-pc-linux-gnu-strip --strip-unneeded usr/lib64/libhpip.so.0.0.1 usr/lib64/python2.4/site-packages/pcardext.so usr/lib64/python2.4/site-packages/cupsext.so usr/sbin/hpiod usr/libexec/cups/backend/hp usr/bin/hpijs removing executable bit: usr/lib64/libhpip.la * checking 1323 files for package collisions 1000 files checked ... existing file /usr/share/cups/model/foomatic-ppds is not owned by this package * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org package net-print/hplip-1.7.3 NOT merged Searching all installed packages for file collisions... Press Ctrl-C to Stop
*** This bug has been marked as a duplicate of bug 80846 ***
Thanks for looking at this. I'm not sure if I understand, the referenced bug is closed and marked resolved fixed. But I don't think that the fix talked about in the comments concerns softlinks; I'm running a recent portage which would include the patch. Are these packages broken, is overwriting symlinks normal (wouldn't that make deleting one of the two packages dangerous?), or is collision-protect inadequate in some way?
(In reply to comment #2) > Are these packages broken, is overwriting symlinks normal (wouldn't that make > deleting one of the two packages dangerous?), or is collision-protect > inadequate in some way? Yes, if one of the packages is unmerged then the symlink might get unmerged (if it's timestamp matches the one in the contents of the package being unmerged). Once bug 16162 is solved it will be possible for packages to install duplicate files as long as they are absolutely identical.
A possible workaround until bug 16162 has been solved would be to create the symlink in the pkg_postinst() function of the ebuild. Then it would bypass collision protection and would not be unmerged when the package is uninstalled.
*** This bug has been marked as a duplicate of bug 16162 ***
I hate to beat a dead horse, but I've taken a closer look at this and I don't think this bug is a duplicate of anything (well, maybe of bug 150574). This isn't a case of portage's facilities being inadequate (as bug 16162), but of misbehaving packages. The install script for foomatic-filters-ppds contains a runtime check for cups and if it finds it installed it will create the symlink. Other than not conforming to "the gentoo way", this is probably bad behavior; nothing in foomatic* requires cups. As for hplip, during the install phase pf hpijs (this bug maybe also applies to hpijs?), in the install-cups subroutine of prnt/hpijs/Makefile, it creates the same symlink. While hplip does require cups, it doesn't require foomatic-filters-ppds. The problem is that these packages are trying to "configure" a different package (cups) where they really shouldn't. The proper fix would be to 1. Either contact upstream of these two packages and ask them to remove this behavior, or simply remove the symlink in both packages at the end of src_install 2. Modify the cups ebuild to add the "foomaticdb" use flag (which already exists) and create the symlink if it is set 3. Add a check to hplip (+hpjis?) to make sure cups is built with USE=foomaticdb How do we make this happen?
This is a portage bug as explained above, not hplip, cups or foomatic one, sorry. There shouldn't be any collisions on symlinks. So no, noone's going to 'fix' the ebuilds because they are not broken in the first place. What's the purpose of reopening this bug over and over again?
The purpose of reopening this bug over and over again is that you keep closing it over and over again for the wrong reasons. The end result manifests itself as a file collision, and while portage may have some inadequacies w.r.t. symlinks, these packages shouldn't be creating them in the first place, as explained above. If you agree, please change it back to ebuilds.
(In reply to comment #4) > A possible workaround until bug 16162 has been solved would be to create the > symlink in the pkg_postinst() function of the ebuild. Then it would bypass > collision protection and would not be unmerged when the package is uninstalled. That'd be even worse than current situation... emerge foo; emerge -C foo; emerge foo -> collision with orphaned cruft installed by foo.
(In reply to comment #6) > The problem is that these packages are trying to "configure" a different > package (cups) where they really shouldn't. The proper fix would be to > > 1. Either contact upstream of these two packages and ask them to remove this > behavior, or simply remove the symlink in both packages at the end of > src_install > 2. Modify the cups ebuild to add the "foomaticdb" use flag (which already > exists) and create the symlink if it is set > 3. Add a check to hplip (+hpjis?) to make sure cups is built with > USE=foomaticdb > > How do we make this happen? > Reassigning to the printing herd so they can decide how they want ot handle the collision between foomatic-filters-ppds and hpijs.
*** Bug 173363 has been marked as a duplicate of this bug. ***
It's now fixed. Please give the fixes an hour or two for them to reach a mirror near you. You'll have to update net-print/cups to the latest version (1.2.10-r1), after unmerging the blockers if any (foomatic-filters-ppds and/or hplip) and remerging them if necessary. Denis.
*** Bug 176962 has been marked as a duplicate of this bug. ***
Please stabilize this package now. Cups 1.2.10-r1 has been stabilized and it's now giving [ebuild U ] net-print/cups-1.2.10-r1 [1.2.9] USE="X dbus jpeg ldap nls pam png ppds samba ssl tiff -php -slp" 3,534 kB [blocks B ] <net-print/hplip-1.7.4a-r1 (is blocking net-print/cups-1.2.10-r1) So please mark hplip-1.7.4a-r1 stable.
