I'm attempting to upgrade my profile $ eselect profile show Current /storage/strogdon/gentoo-rap/etc/portage/make.profile symlink: default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ to default/linux/amd64/17.1/no-multilib/prefix/kernel-3.2+ $ eselect profile list Available profile symlink targets: [1] prefix/linux/amd64 (exp) [2] default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ (dev) * [3] default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+ (exp) [4] default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ (exp) [5] default/linux/amd64/17.1/no-multilib/prefix/kernel-3.2+ (dev) [6] default/linux/amd64/17.1/no-multilib/prefix/kernel-2.6.32+ (exp) [7] default/linux/amd64/17.1/no-multilib/prefix/kernel-2.6.16+ (exp) The required upgrade instructions involve using unsymlink-lib and the first step fails with: $ unsymlink-lib --analyze [Running as unprivileged user, results will not be saved] Traceback (most recent call last): File "/storage/strogdon/gentoo-rap/usr/lib/python-exec/python3.7/unsymlink-lib", line 830, in <module> main() File "/storage/strogdon/gentoo-rap/usr/lib/python-exec/python3.7/unsymlink-lib", line 701, in main if os.path.samefile(lib64_dir, usr_lib64_dir): File "/storage/strogdon/gentoo-rap/usr/lib/python3.7/genericpath.py", line 101, in samefile s2 = os.stat(f2) FileNotFoundError: [Errno 2] No such file or directory: b'/usr/lib64' It appears unsymlink-lib looks for root privileges $ unsymlink-lib --migrate --pretend usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] [--rollback] [--finish] [--force-rollback] [--resume-finish] [-P PREFIX] [--hardlink] unsymlink-lib: error: Requested action requires root privileges It doesn't appear that unsymlink-lib can be used to make the profile upgrade.
Indeed, I didn't account for unprivileged installs. Could you try removing this condition and seeing if --prefix option works at all?
Is this necessary at all on Prefix?
After skimming through the unsymlink-lib code, I think the necessary calling convention would be "unsymlink-lib --root EROOT", replacing EROOT with the prefix path. That should cause the script to look for ${EROOT}/lib, ${EROOT}/usr/lib, etc.
(In reply to Fabian Groffen from comment #2) > Is this necessary at all on Prefix? It would allow people to migrate from SYMLINK_LIB=yes (17.0) to SYMLINK_LIB=no (17.1) without doing a fresh prefix install.
(In reply to Mike Gilbert from comment #3) > After skimming through the unsymlink-lib code, I think the necessary calling > convention would be "unsymlink-lib --root EROOT", replacing EROOT with the > prefix path. > > That should cause the script to look for ${EROOT}/lib, ${EROOT}/usr/lib, etc. unsymlink-lib --root /storage/strogdon/gentoo-rap --analyze does give meaningful output. My prefix is /storage/strogdon/gentoo-rap. This terminates with Everything looks good from here. However, you need to rerun the process as root to confirm. But root privilege is still needed: unsymlink-lib --root /storage/strogdon/gentoo-rap --migrate --pretend usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] [--rollback] [--finish] [--force-rollback] [--resume-finish] [-P PREFIX] [--hardlink] unsymlink-lib: error: Requested action requires root privileges
If you feel like being a guinea pig, remove this code from the script and give it a try. https://github.com/mgorny/unsymlink-lib/blob/v18/unsymlink-lib#L682-L686
Looks like you would also need to adjust this section: https://github.com/mgorny/unsymlink-lib/blob/v18/unsymlink-lib#L725-L740
Removing those lines I have $ unsymlink-lib --root /storage/strogdon/gentoo-rap --analyze terminates with directories that will be moved to /storage/strogdon/gentoo-rap/usr/local/lib/: (+ 0 files) directories whose contents will be split between /storage/strogdon/gentoo-rap/usr/local/lib/ and /storage/strogdon/gentoo-rap/usr/local/lib64/: Warning: no lib32 paths found. This is fine if you are running no-multilib, otherwise this is suspicious. This seems OK. And then $ unsymlink-lib --root /storage/strogdon/gentoo-rap --migrate --pretend State file could not be loaded. Did you run --analyze? So something isn't saved from the --analyze step.
Perhaps the m.save_state() is needed.
(In reply to Steven Trogdon from comment #9) > Perhaps the m.save_state() is needed. Right.
Retaining just m.save_state() log('') log('') log('The state has been saved and the migration is ready to proceed.') log('To initiate it, please run:') log('') log('\t{} --migrate', sys.argv[0]) log('') log('Please do not perform any changes to the system at this point.') log('If you performed any changes, please rerun the analysis.') in https://github.com/mgorny/unsymlink-lib/blob/v18/unsymlink-lib#L725-L740 seems to work.
Thank you. I'm adding tests for prefix scenarios as we speak, and should be able to make a release in the next hour or so.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=10f7e8061b7f780e7ba008281e1bd920b5ab5c8a commit 10f7e8061b7f780e7ba008281e1bd920b5ab5c8a Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-11-09 22:06:52 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-11-09 22:08:07 +0000 app-portage/unsymlink-lib: Bump to v19 Closes: https://bugs.gentoo.org/753743 Signed-off-by: Michał Górny <mgorny@gentoo.org> app-portage/unsymlink-lib/Manifest | 1 + app-portage/unsymlink-lib/unsymlink-lib-19.ebuild | 29 +++++++++++++++++++++++ 2 files changed, 30 insertions(+)
Thanks guys. @Fabian, I regard keeping Prefix directory structures in sync with Gentoo vanilla gives least surprise to our users.
I thought I would comment here before opening another bug. I followed the procedure to upgrade to the 17.1 profile using --root EPREFIX and --unprivileged where needed. After restarting prefix, executing the --finish step and eselecting the 17.1 profile my gcc is apparently broken. Wnen rebuilding gcc-10.2.0 I have /storage/strogdon/gentoo-rap/var/tmp/portage/sys-devel/gcc-10.2.0-r3/work/gcc-10.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/storage/strogdon/gentoo-rap/usr --bindir=/storage/strogdon/gentoo-rap/usr/x86_64-pc-linux-gnu/gcc-bin/10.2.0 --includedir=/storage/strogdon/gentoo-rap/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include --datadir=/storage/strogdon/gentoo-rap/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0 --mandir=/storage/strogdon/gentoo-rap/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/man --infodir=/storage/strogdon/gentoo-rap/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/info --with-gxx-include-dir=/storage/strogdon/gentoo-rap/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 10.2.0-r3 p4 --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --enable-vtable-verify --without-zstd --enable-lto --without-isl --enable-default-pie --enable-default-ssp --with-sysroot=/storage/strogdon/gentoo-rap checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /storage/strogdon/gentoo-rap/usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /storage/strogdon/gentoo-rap/bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... yes checking for libhsail-rt support... yes checking for libphobos support... yes checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... no configure: error: in `/storage/strogdon/gentoo-rap/var/tmp/portage/sys-devel/gcc-10.2.0-r3/work/build': configure: error: C compiler cannot create executables See `config.log' for more details
This is apparently the problem. From config.log configure:4483: x86_64-pc-linux-gnu-gcc conftest.c >&5 /storage/strogdon/gentoo-rap/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/as: error while loading shared libraries: libopcodes-2.30.0.so: cannot open shared object file: No such file or directory
It appears that binutils wasn't moved from EPREFIX/usr/lib to EPREFIX/usr/lib64 ls /storage/strogdon/gentoo-rap/usr/lib/binutils x86_64-pc-linux-gnu
(In reply to Benda Xu from comment #14) > Thanks guys. > > @Fabian, I regard keeping Prefix directory structures in sync with Gentoo > vanilla gives least surprise to our users. that's fine, but the problem is that people are breaking their systems at this point :(
I have met problems on prefix installations unsymlink-lib --root /opt/gentoo --analyze gives orphan dirs/files (not owned by any package) that will be moved to /opt/gentoo/usr/lib/: CLHEP-2.4.1.3 ..... ..... But those directories are owned by packages. # equery b CLHEP-2.4.1.3 * Searching for CLHEP-2.4.1.3 ... sci-physics/clhep-2.4.1.3-r2 (/opt/gentoo/usr/lib64/CLHEP-2.4.1.3) The analyze result is not correct.
Patch sent. I made a successful migration to 17.1 prefix profile.
The patch was merged in https://github.com/projg2/unsymlink-lib/commit/22c4790869996627492390f7285ece0dfdf4221b and is in v20. Is there anything left for Prefix now?
