Profile 23.0 upgrade

[ipic]

There used to be a group - @system - that was intended for this.

Seriously - forcing a rebuild on a system where it would take the best part of a 24 hour day should never be an option.
"Enforcing" things has never been the Gentoo way either.

[Hu]

No, @system is the set of packages that all ebuilds can assume are installed. It may contain non-program packages, such as virtuals, which do not need to be rebuilt here. It usually will omit at least some packages that deserve a rebuild on a toolchain improvement, because those packages are not system critical. Thus, it fails in both directions. sam_'s comment about searching the VDB is what I had in mind, and yes, that is a somewhat ugly approach, but I cannot think of an alternative that will (1) find all packages which can benefit, (2) exclude all packages that clearly cannot benefit (documentation, scripts), (3) avoid trying to rebuild things which are not packages (/usr/local/bin/ programs). It's still not perfect, since it will flag for inclusion things which distribute ELF files prebuilt upstream (such as firefox-bin), but it excludes quite a bit that --emptytree would include. It might be possible to abuse some of the ebuild's QA_ variables to identify prebuilt files and exclude them from the package's effective contents before deciding whether it ships anything worth rebuilding.

As for forcing - users are of course free to ignore the recommended path. This path is recommended because it is the simplest way to ensure that all packages which can benefit are rebuilt so that they do benefit. Identifying specific packages out of the VDB would be nice, but I expect that most packages excluded that way are cheap to build. If you have a long total build time, it is likely because you have many packages which are compiled by your toolchain, so excluding the unnecessary ones will not help you much. It would mainly be a savings on write cycles for limited life storage devices.

[NeddySeagoon]

ipic,

Nothing is enforced, only recommended. The further you stray from the beaten path, the less sympathy and help you are likely to get. That's not a reason to not do it, as long as you understand you can keep the pieces if it breaks.

I still use a static /dev, separate /usr and root in LVM, all without an initrd. I'm old any cynical, I know that that when it breaks, I won't even get a shoulder to cry on. :)
I had to add an initrd to mount /usr the other day but I was warned beforehand, so when it broke, it was just another entry on the syslinux menu.

"Because I can" is an excellent reason to do something with Gentoo :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[ipic]

[sam_]

Enforcing has a specific meaning wrt security measures. In this case, it means "[allowing users to] ask glibc to enforce it" (and testing that a lot, and fixing any breakage, and documenting it), not enforcing it upon all users (i.e. making users use CET whether they like it or not).

That is, enforcing of the measure onto applications, not onto users. Why would I want to "enforce" anything on our users?

I have no idea if we could get to a point where that was done on all CPUs without opting-in at any point, and even then, it's not like it'd be mandatory.

[ipic]

[Hu]

[ipic]

[Hu]

That only built packages which were out of date or which had a pending USE flag change. Per earlier remarks in the thread, any packages for which you have the current version, but which were built with an older toolchain, have not been rebuilt and are not benefiting from the improvements built into the new profile. You will eventually rebuild those with the new toolchain as updates become available, but for some projects, that could be quite a ways in the future.

[UlvHare]

Do I need to move to merged-usr (

[flysideways]

UlvHare,

The table found here: https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table , suggests, default/linux/amd64/17.1/desktop/plasma --> default/linux/amd64/23.0/split-usr/desktop/plasma

[flysideways]

Four of the six provided links are broken here

[houtworm]

I am almost at the end of the news message about this topic. Now I have to rebuild world. I have a lot of binary packages because this pc also builds for other pc's. Can I still use these binary packages, or do I have to rebuild everything?
_________________
niemand is onbekwamer, dan een timmerman zonder hamer

Kees

[Hu]

[CaptainBlood]

[mkyral]

It looks like openrc binpkg installs binaries to wrong place (/usr/sbin) and kernel can't find /sbin/openrc to run and boot fails. I had to force portage to compile openrc package. Then correct folders are used and my system boots again.

I'm on default/linux/amd64/23.0/split-usr/desktop/plasma profile, split-usr USE flag is set, but there is no such flag on openrc.

[figueroa]

Sam_, your explanations and your patience are greatly appreciated. I haven't found the instructions difficult to follow. But, I have a question.

On an old x86 openrc system (CHOST="i686-pc-linux-gnu" with an AMD Phenom CPU) migrating from [5] to [28], and having just compiled binutils, gcc, and glibc with no CHOST or version changes, would it be sound to use selected excludes in the --emptytree rebuild in order to speed things up.

[e8root]

[UlvHare]

[logrusx]

[Havin_it]

[thrashed]

yesterday i migrated from "default/linux/amd64/17.1" to "default/linux/amd64/23.0"

i read https://www.gentoo.org/support/news-items/2024-03-22-new-23-profiles.html calmly and in detail.
and to be honest i skipped point 16. --> Rebuild world: "emerge --ask --emptytree @world".

instead of point 16, i just updated world, like i always did all the years and on this update the successfull build of sys-apps/baselayout-2.14-r2 broke my system. after this successfull build, every other emerge was not possible anymore (PORTAGE_BZIP2_COMMAND setting is invalid: 'bzip2' error messages and so on). i figured out, that /sbin and /bin were missing in my PATH variable. adjusting the PATH variabel in /etc/profile did not help, because every env-update freshly writes the PATH variable in /etc/profile. In /etc/env.d/50baselayout i found, that /sbin and /bin were missing in the PATH variable and in ROOTPATH variable. after adapting /sbin and /bin to the variables in /etc/env.d/50baselayout everyhting worked again.

actually i run the recommended "emerge --ask --emptytree @world", hope after this is everything done for the successfull profile change.

because I was very interested in it, i tried to figure out what caused my problem.
in baselayout-2.14-r2.ebuild you can read from line 198-204

[pietinger]

[GDH-gentoo]

[figueroa]

I suspect that you should have migrated to the split-usr profile: