Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Mick]

On Thursday, 30 May 2019 02:18:01 BST Dale wrote:

> I haven't tested the 17.1 profile yet.  If you are unsure, I'd just use
> 17.0 and wait until 17.1 is released.
>
> Dale
>
> :-)  :-)

The 17.1 profile does away with separate /lib directories as explained here:

https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout

From the relevant enews item:

===========================================
2017-12-26-experimental-amd64-17-1-profiles
  Title                     Experimental amd64 17.1 profiles up for testing
  Author                    Michał Górny <mgorny@g.o>
  Posted                    2017-12-26
  Revision                  3

A new set of 17.1 amd64 profiles has been added to the Gentoo
repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
multilib layout, and require explicit migration as described below. They
are considered experimental at the moment, and have a fair risk
of breaking your system. We would therefore like to ask our users to
test them on their non-production ~amd64 systems.

In those profiles, the lib->lib64 compatibility symlink is removed.
The 'lib' directory becomes a separate directory, that is used
for cross-arch and native non-library packages (gcc, clang) and 32-bit
libraries on the multilib profile (for better compatibility with
prebuilt x86 packages).

Migration from both 13.0 and 17.0 profiles is supported. In case
of the former, please read the news item for 17.0 upgrade first
and enable gcc 6.4.0 or newer first as explained there.

The migration is performed using app-portage/unsymlink-lib tool.
The following steps can be used to upgrade your system:

1. Sync and upgrade your system to the newest package versions
   to reduce the risk of issues.

2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib'

3. Run 'unsymlink-lib --analyze' and check the output for obvious
   mistakes. If you need to perform any changes to the system, remember
   to run 'unsymlink-lib --analyze' again afterwards.

[past this point do not call emerge or modify /usr manually]

4. This is a very good time to make a backup.

5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
   what is going to happen.

6. Reboot your system and see if it still boots. Check if important
   programs work. In particular, check if e.g. 'emerge --info' works
   (but do not install anything). If you hit any serious problems,
   you can use 'unsymlink-lib --rollback' to revert the changes
   and return to step 3.

7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
   what is going to happen but note that you're going to see a very long
   list of files to remove.

8. Switch the profile, e.g.:

     eselect profile set --force default/linux/amd64/17.1/desktop

[at this point you can start using emerge again]

9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles,
   rebuild sys-devel/binutils and sys-libs/glibc afterwards.

10. If you are using a multilib profile, rebuild all 32-bit packages.
    This can be done using:

      emerge -1v /lib32 /usr/lib32

    Alternatively, if you are switching from one of the 13.0 profiles
    you can rebuild all packages as detailed in the 17.0 news item.

11. Once the last 32-bit package is rebuilt, your package manager
    should remove the orphaned /lib32 and /usr/lib32 symlinks. If that
    does not happen, remove them manually.

For known issues, please see bug #506276 [1]. If you have any problems
with the new profiles or the migration procedure, please report a bug
and make it block the tracker.

For more information on the layout, please see the wiki article
on AMD64 multilib layouts [2].

[1]:https://bugs.gentoo.org/506276
[2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
==============================================================


BTW, the OP may want to read the enews item for upgrading to 17.0 profile 
first, just in case he needs to make any changes to his gcc and rebuild his 
toolchain:

==========================
2017-11-30-new-17-profiles
  Title                     New 17.0 profiles in the Gentoo repository
  Author                    Andreas K. Hüttel <dilfridge@g.o>
  Posted                    2017-11-30
  Revision                  1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo 
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
   This change is mostly relevant to Gentoo developers. It also
   means, however, that compilers earlier than GCC 6 are masked 
   and not supported for use as a system compiler anymore. Feel 
   free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
   executables (PIE) by default. This improves the overall
   security fingerprint. The switch from non-PIE to PIE binaries,
   however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
   profile tree. Now they are moving into the 17.0 profile
   as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps: 
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
    . /etc/profile
* Re-emerge libtool
    emerge -1 sys-devel/libtool
Then, 
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
    emerge -1 sys-devel/gcc:6.4.0
    emerge -1 sys-devel/binutils
    emerge -1 sys-libs/glibc
* Rebuild your entire system
    emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of 
GCC 6 to generate PIE executables by default; thus, you need to do 
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.
=============

HTH.
-- 
Regards,
Mick