W dniu sob, 19.08.2017 o godzinie 15∶25 -0700, użytkownik Georgy Yakovlev napisał: > I've found couple of issues, or maybe not. > > systemd installs to /usr/lib/systemd (or /lib/systemd since 234) > unconditionally. > I'm not sure if it's special and should be allowed to do that, but it's > the only package on the system (except gcc/$CHOST dir) that has 64-bit > libraries and binaries in lib.
Yes, this is valid. /usr/lib/foo is equivalent to /usr/libexec/foo on modern systems, and some packages prefer the former over the latter. > Here is the list of the bugs I've found and opened, maybe you can add > them as blockers for #506276 > > https://bugs.gentoo.org/show_bug.cgi?id=627744 > https://bugs.gentoo.org/show_bug.cgi?id=627746 Assigned and blocked, thanks. > https://bugs.gentoo.org/show_bug.cgi?id=628338 > > > > On 08/12/2017 02:33 PM, Michał Górny wrote: > > On śro, 2017-08-02 at 17:58 +0200, Michał Górny wrote: > > > Hi, everyone. > > > > > > I've finally gotten around to writing a new tool for migrating amd64 > > > systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib- > > > migration [2] repository along with a README. Please review it and give > > > it more testing. > > > > I've pushed two important fixes now: > > > > a. The tool now processes unowned files as well -- *.{a,la,so} are left > > in lib64 (i.e. the symlinks created by db.eclass and alikes) while > > everything else goes into lib. > > > > b. I've fixed cleanup phase to also remove top-level files > > and directories that were moved out of lib64. Also, I've fixed it not to > > complain about trying to remove non-empty directories. > > > > > > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276 > > > [2]:https://github.com/mgorny/symlink-lib-migration > > -- Best regards, Michał Górny
