When unmerging app-dicts/aspell-es-0.50.2, portage-2.1.10.49 fails to unmerge a file named español.alias and leaves it behind as an orphan. # emerge -C -v app-dicts/aspell-es * This action can remove important packages! In order to be safer, use * `emerge -pv --depclean <atom>` to check for reverse dependencies before * removing packages. app-dicts/aspell-es selected: 0.50.2 protected: none omitted: none All selected packages: app-dicts/aspell-es-0.50.2 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging app-dicts/aspell-es-0.50.2... No package files given... Grabbing a set. <<< obj /usr/share/doc/aspell-es-0.50.2/info.xz <<< obj /usr/share/doc/aspell-es-0.50.2/README.xz <<< obj /usr/lib64/aspell-0.60/spanish.alias <<< obj /usr/lib64/aspell-0.60/esponol.alias --- !found obj /usr/lib64/aspell-0.60/español.alias <<< obj /usr/lib64/aspell-0.60/es.rws <<< obj /usr/lib64/aspell-0.60/es.multi <<< obj /usr/lib64/aspell-0.60/es.dat <<< dir /usr/share/doc/aspell-es-0.50.2 --- !empty dir /usr/share/doc --- !empty dir /usr/share --- !empty dir /usr/lib64/aspell-0.60 --- !empty dir /usr/lib64 --- !empty dir /usr * GNU info directory index is up-to-date. # ls /usr/lib64/aspell-0.60/esp* /usr/lib64/aspell-0.60/español.alias # cd /usr/lib64/aspell-0.60; ls esp* | hexdump -C 00000000 65 73 70 61 f1 6f 6c 2e 61 6c 69 61 73 0a |español.alias.| 0000000e This is with LANG=de_DE.ISO-8859-1 as locale setting. Unmerging aspell-es on another system that still had portage-2.1.10.11 (and same locale settings) succeeded without problems. Therefore marking this as regression.
This is expected as a result of migration to UTF-8 encoding for all locales, as mentioned in bug 382199, comment #8.
Maybe both translations (utf-8 and user's locale) could be tried when unmerging files with non-ascii characters?
It's probably not worth the trouble, given that it's only a transitional issue.
(In reply to comment #3) > It's probably not worth the trouble, given that it's only a transitional > issue. Indeed, and probably there are only few packages affected. So feel free to close this bug. BTW, when I reinstall the package, portage now renames mentioned file to espa\ufffdol.alias. Maybe it would be more consequent to abort the merge in case a bad filename is encountered, instead of installing files with such garbled names?
Well, it seems a little harsh to abort. We could add a layout.conf setting to indicate that ebuilds from a given repo should abort if they install file names that aren't valid UTF-8. A QA Notice could be triggered when it's not configured to abort.
layout.conf looks like overkill, but I think a QA notice would be appropriate.
It's fixed to use eqawarn: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=141408ea103bb3217a9204577a26d4c0724401ad
This QA Notice is in 2.2.0_alpha91, but I'll leave this bug open until it's in an unmasked release.
This is fixed in 2.1.10.50.
