| 1 |
Hi, |
| 2 |
|
| 3 |
I was able to test this one a bit. |
| 4 |
The test subjects were: |
| 5 |
~amd64/openrc/desktop system which I was going to wipe anyway. |
| 6 |
amd64/openrc latest snapshot, updated to ~amd64 with boostrtap.sh |
| 7 |
|
| 8 |
for the latter symlink migration was done before bootstrapping, |
| 9 |
|
| 10 |
|
| 11 |
So far I found 3 issues so far: |
| 12 |
|
| 13 |
1) kernel modules. modprobe looks into /lib/modules/$(uname -r), but |
| 14 |
after running the tool they end up in /lib64/modules. |
| 15 |
|
| 16 |
2) app-eselect/eselect-mesa has some hardcoded paths: |
| 17 |
MESA_CONF_DIR="${EROOT}/usr/share/mesa" |
| 18 |
MESA_DIR_64="${EROOT}/usr/lib/mesa" |
| 19 |
DRI_DIR_64="${EROOT}/usr/lib/dri" |
| 20 |
MESA_DIR_32="${EROOT}/usr/lib32/mesa" |
| 21 |
DRI_DIR_32="${EROOT}/usr/lib32/dri" |
| 22 |
that leads to many funny breakages. |
| 23 |
|
| 24 |
3) and minor one, sys-boot/refind will fails to build, because it looks |
| 25 |
for 64bit libs in lib. |
| 26 |
|
| 27 |
|
| 28 |
I'm going to play with the system next couple of weeks and If I find |
| 29 |
anything else I'll let you know. |
| 30 |
|
| 31 |
|
| 32 |
Regards, |
| 33 |
|
| 34 |
Georgy Yakovlev. |
| 35 |
|
| 36 |
On 08/02/2017 08:58 AM, Michał Górny wrote: |
| 37 |
> Hi, everyone. |
| 38 |
> |
| 39 |
> I've finally gotten around to writing a new tool for migrating amd64 |
| 40 |
> systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib- |
| 41 |
> migration [2] repository along with a README. Please review it and give |
| 42 |
> it more testing. |
| 43 |
> |
| 44 |
> The tool has a few advantages over the one attached to the bug. Most |
| 45 |
> notably: |
| 46 |
> |
| 47 |
> 1. It runs in three-stage semi-automatic mode. This gives the user |
| 48 |
> an explicit opportunity to verify the action plan for any obvious |
| 49 |
> mistakes, and to test a temporary 'lib.new' layout to confirm that |
| 50 |
> the migration won't break anything before it's final. |
| 51 |
> |
| 52 |
> 2. It supports a mid-migration rollback -- if 'lib.new' layout breaks |
| 53 |
> stuff, the user runs './migrate.py --rollback' and he's back home. |
| 54 |
> |
| 55 |
> 3. It works on top-directory level whenever possible. The stuff destined |
| 56 |
> for /usr/lib is moved correctly along with any user-created files. When |
| 57 |
> a top-directory is split between lib+lib64, all files except for those |
| 58 |
> explicitly destined for lib64 land in lib (arbitrary decision). |
| 59 |
> |
| 60 |
> 4. It does not reinvent the wheel poorly to copy files. Instead, it |
| 61 |
> calls 'cp -a --reflink=auto ...' to guarantee that everything will be |
| 62 |
> preserved correctly. |
| 63 |
> |
| 64 |
> 5. It does not reinvent the wheel to parse vdb. Instead, it uses |
| 65 |
> the Portage API to get installed file list. Portage is only required |
| 66 |
> during the initial analysis phase, and the actual migration/rollback can |
| 67 |
> be done without it (or with it being broken). |
| 68 |
> |
| 69 |
> I've limited the scope of the tool to do the filesystem manipulation. |
| 70 |
> Afterwards, it tells user to update the profile or adjust make.conf, |
| 71 |
> and to rebuild all the packages. |
| 72 |
> |
| 73 |
> What are your thoughts? |
| 74 |
> |
| 75 |
> |
| 76 |
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276 |
| 77 |
> [2]:https://github.com/mgorny/symlink-lib-migration |
| 78 |
> |
Archives