Hi,

I was able to test this one a bit.
The test subjects were:
 ~amd64/openrc/desktop system which I was going to wipe anyway.
 amd64/openrc latest snapshot, updated to ~amd64 with boostrtap.sh

for the latter symlink migration was done before bootstrapping,


So far I found 3 issues so far:

1) kernel modules. modprobe looks into /lib/modules/$(uname -r), but
after running the tool they end up in /lib64/modules.

2) app-eselect/eselect-mesa  has some hardcoded paths:
        MESA_CONF_DIR="${EROOT}/usr/share/mesa"
        MESA_DIR_64="${EROOT}/usr/lib/mesa"
        DRI_DIR_64="${EROOT}/usr/lib/dri"
        MESA_DIR_32="${EROOT}/usr/lib32/mesa"
        DRI_DIR_32="${EROOT}/usr/lib32/dri"
that leads to many funny breakages.

3) and minor one, sys-boot/refind will fails to build, because it looks
for 64bit libs in lib.


I'm going to play with the system next couple of weeks and If I find
anything else I'll let you know.


Regards,

Georgy Yakovlev.

On 08/02/2017 08:58 AM, 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.
> 
> The tool has a few advantages over the one attached to the bug. Most
> notably:
> 
> 1. It runs in three-stage semi-automatic mode. This gives the user
> an explicit opportunity to verify the action plan for any obvious
> mistakes, and to test a temporary 'lib.new' layout to confirm that
> the migration won't break anything before it's final.
> 
> 2. It supports a mid-migration rollback -- if 'lib.new' layout breaks
> stuff, the user runs './migrate.py --rollback' and he's back home.
> 
> 3. It works on top-directory level whenever possible. The stuff destined
> for /usr/lib is moved correctly along with any user-created files. When
> a top-directory is split between lib+lib64, all files except for those
> explicitly destined for lib64 land in lib (arbitrary decision).
> 
> 4. It does not reinvent the wheel poorly to copy files. Instead, it
> calls 'cp -a --reflink=auto ...' to guarantee that everything will be
> preserved correctly.
> 
> 5. It does not reinvent the wheel to parse vdb. Instead, it uses
> the Portage API to get installed file list. Portage is only required
> during the initial analysis phase, and the actual migration/rollback can
> be done without it (or with it being broken).
> 
> I've limited the scope of the tool to do the filesystem manipulation.
> Afterwards, it tells user to update the profile or adjust make.conf,
> and to rebuild all the packages.
> 
> What are your thoughts?
> 
> 
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276
> [2]:https://github.com/mgorny/symlink-lib-migration
> 

Reply via email to