Bugzilla Bug 172341

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.