Upgrading a package where a directory is replaced with a symlink silently leaves the directory intact and discards the symlink. sys-apps/portage has a similar issue, bug 326685. When the package is later unmerged, the directory will remain as an orphaned filesystem object. Reproducible: Always Steps to Reproduce: 1. emerge =kiwix-0.9_alpha7 2. emerge --onlydeps =kiwix-0.9_beta1 3. pmerge --nodeps =kiwix-0.9_beta1 Actual Results: $ ls -l /usr/lib64/kiwix/ drwxr-xr-x 1 root root 0 23. Jul 19:19 chrome drwxr-xr-x 1 root root 0 23. Jul 19:19 defaults Expected Results: $ ls -l /usr/lib64/kiwix/ lrwxrwxrwx 1 root root 23 23. Jul 18:54 chrome -> /usr/share/kiwix/chrome lrwxrwxrwx 1 root root 25 23. Jul 18:54 defaults -> /usr/share/kiwix/defaults
Violates PMS; see https://bugs.gentoo.org/show_bug.cgi?id=326685#c5 ; this is a bug in the ebuild for attempting it...
Lack of responses means I slap this shut; per the norm, pkgcore will *not* violate PMS standards- if PMS EAPI says xyz, then xyz is the rule. If you want this behaviour, you need a seperate EAPI (whether a new pms derived one, or a custom/local one).
I don't see any question which needs a response? Btw. the reverse case (directory replaces symlink) is even more broken and not forbidden by PMS.
(In reply to comment #3) > I don't see any question which needs a response? "Violates pms" kind of requires a response... > Btw. the reverse case (directory replaces symlink) is even more broken and not > forbidden by PMS. Arguable in breakage; frankly making this change is pretty easy, but I'm tired of having to track what portage does rather than what the spec says. As such I'm taking a hardline on it- write your ebuilds to PMS spec, or call it a different EAPI. I probably will *support* the seperate EAPI, but no more pissing on the spec- it costs me too much time dealing w/ that crap.