... When installing 'net-www/mozplugger-1.10.2:0::gentoo': ... When merging 'net-www/mozplugger-1.10.2:0::gentoo' at '/var/tmp/paludis/net-www-mozplugger-1.10.2/image' to VDB repository 'installed': ... When checking merge from '/var/tmp/paludis/net-www-mozplugger-1.10.2/image' to '/': ... When checking merge from '/var/tmp/paludis/net-www-mozplugger-1.10.2/image' to '/': ... When checking merge from '/var/tmp/paludis/net-www-mozplugger-1.10.2/image/usr' to '/usr': ... When handling dir '/var/tmp/paludis/net-www-mozplugger-1.10.2/image/usr/lib' to '/usr': ... Expected '/usr/lib' to be a directory but found a symlink to a directory ... !!! Cannot overwrite directory '/usr/lib/mozilla/plugins' with symlink '/var/tmp/paludis/net-www-mozplugger-1.10.2/image/usr/lib/mozilla/plugins' Reproducible: Always
Seems like paludis doesn't like dosym ${1} /usr/$(get_libdir)/${PLUGINS_DIR} from eclass/nsplugins.eclass
Not a paludis bug.
Let's try again. If you cannot accept that the bug has something to do with paludis, then at least you can explain where eclass/nsplugins.eclass fails to meet some standard.
Overwriting a dir with a symlink is unsafe. That should be a fatal error. Either the user needs to get rid of the dir before merging the package in question or the ebuild needs to handle it in pkg_preinst. What is the output of paludis --full-match --owner /usr/lib/mozilla/plugins ?
Emerging that version of mozplugger also results in a file collison ("/usr/lib/mozilla/plugins") with gnome-base/librsvg-2.22.3.
The issue went away for me after upgrading to the latest librsvg-2.22.3 using paludis. Not sure what's going on here. But qfile originally report the dir to be owned by librsvg. After paludis librsvg upgrade, it says no one is owning it. After mozplugger is installed, the two packages seem to agree on a joint ownership: blessing /home/clement # qfile /usr/lib/mozilla/plugins gnome-base/librsvg (/usr/lib64/mozilla/plugins) net-www/mozplugger (/usr/lib64/mozilla/plugins) blessing /home/clement # paludis --full-match --owner /usr/lib/mozilla/plugins * /usr/lib/mozilla/plugins blessing /home/clement # paludis --full-match --owner /usr/lib64/mozilla/plugins * /usr/lib64/mozilla/plugins gnome-base/librsvg-2.22.3:2::installed net-www/mozplugger-1.10.2:0::installed And they lived happily ever after: blessing /home/clement # paludis --query librsvg mozplugger * gnome-base/librsvg gentoo: 2.20.0 2.22.2 2.22.3 {:2} installed: 2.22.3* {:2} Description: Scalable Vector Graphics (SVG) rendering library Homepage: http://librsvg.sourceforge.net/ License: LGPL-2 Installed time: Sun Mar 22 03:57:18 2009 Use flags: (-debug) (-doc) (zlib) From repositories: gentoo Installed using: paludis-0.36.0 * net-www/mozplugger gentoo: 1.7.3-r1(~) 1.10.2(~) {:0} installed: 1.10.2* {:0} Description: Streaming media plugin for Mozilla, based on netscape-plugger Homepage: http://mozplugger.mozdev.org/ License: GPL-2 Installed time: Sun Mar 22 03:58:22 2009 Use flags: From repositories: gentoo Installed using: paludis-0.36.0 Key to mask reasons: * ~: keyword (unstable accepted)
And reason for resolving this as INVALID was ...?
(In reply to comment #7) > And reason for resolving this as INVALID was ...? > Maybe because this is a typical “use Portage instead” bug? ;-) I had the same issue with www-plugins/mozplugger-1.14.0 and paludis 0.48.5 and and "emerge mozplugger" solved it (but I'll keep on using paludis because I really like it). /usr/lib has always been a symlink to /usr/lib64 on my box since I use amd64 - can anybody please explain why "Overwriting a dir with a symlink is unsafe." and why this must be an error and not just a warning? As I never had this issue before with any other package I blame it on the ebuild.
(In reply to comment #8) > Maybe because this is a typical “use Portage instead” bug? ;-) Using portage is potentially dangerous. What happens to the contents of a directory when the directory is overwritten with a symlink? The behaviour is undefined. > /usr/lib has always been a symlink to /usr/lib64 on my box since I use amd64 - > can anybody please explain why "Overwriting a dir with a symlink is unsafe." > and why this must be an error and not just a warning? We're not talking about merging over a symlink here. We're talking about replacing a directory with a symlink. > As I never had this issue before with any other package I blame it on the > ebuild. If librsvg still installs this directory there is a collision which needs to be resolved. If librsvg stopped installing a directory and mozplugger needs to replace it with a symlink then the proper way of handling the migration is a pkg_preinst() which takes care of the directory if it exists.
cause I can :)
Everything should install fine now, if bug resurfaces feel free to reopen.
