1 |
Hi, everyone. |
2 |
|
3 |
I've finally gotten around to writing a new tool for migrating amd64 |
4 |
systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib- |
5 |
migration [2] repository along with a README. Please review it and give |
6 |
it more testing. |
7 |
|
8 |
The tool has a few advantages over the one attached to the bug. Most |
9 |
notably: |
10 |
|
11 |
1. It runs in three-stage semi-automatic mode. This gives the user |
12 |
an explicit opportunity to verify the action plan for any obvious |
13 |
mistakes, and to test a temporary 'lib.new' layout to confirm that |
14 |
the migration won't break anything before it's final. |
15 |
|
16 |
2. It supports a mid-migration rollback -- if 'lib.new' layout breaks |
17 |
stuff, the user runs './migrate.py --rollback' and he's back home. |
18 |
|
19 |
3. It works on top-directory level whenever possible. The stuff destined |
20 |
for /usr/lib is moved correctly along with any user-created files. When |
21 |
a top-directory is split between lib+lib64, all files except for those |
22 |
explicitly destined for lib64 land in lib (arbitrary decision). |
23 |
|
24 |
4. It does not reinvent the wheel poorly to copy files. Instead, it |
25 |
calls 'cp -a --reflink=auto ...' to guarantee that everything will be |
26 |
preserved correctly. |
27 |
|
28 |
5. It does not reinvent the wheel to parse vdb. Instead, it uses |
29 |
the Portage API to get installed file list. Portage is only required |
30 |
during the initial analysis phase, and the actual migration/rollback can |
31 |
be done without it (or with it being broken). |
32 |
|
33 |
I've limited the scope of the tool to do the filesystem manipulation. |
34 |
Afterwards, it tells user to update the profile or adjust make.conf, |
35 |
and to rebuild all the packages. |
36 |
|
37 |
What are your thoughts? |
38 |
|
39 |
|
40 |
[1]:https://bugs.gentoo.org/show_bug.cgi?id=506276 |
41 |
[2]:https://github.com/mgorny/symlink-lib-migration |
42 |
|
43 |
-- |
44 |
Best regards, |
45 |
Michał Górny |