On 02/04/2024 04:51, John Covici wrote:
My kernels are not in the world file at all, so I am confused why
portage should care about them when I am updating the world file. My
question is why do I need to do this at all -- could I just keep
updating as normal?
Your kernels should be in the world file as evidenced by your earlier
log and pointed out by J. Roeleveld. If you didn't, portage would try to
remove it - its sources, at least - every time you ran portage with
"--depclean".
Unfortunately, kernels are periodically 'hoovered' from the Gentoo repo
and it appears 6.1.69 has already been removed and superseded by 6.1.74,
6.1.81, 6.1.82, and 6.1.83 in the 6.1.x family. Chances are your config
would work just as well on these.
The reason you have to do this is because with the upstream ebuild now
gone, portage doesn't know how to fetch said ebuild. This is not a
problem on a day-to-day basis as you would only be emerging packages
with updates or
use flag changes. But with --emptytre portage is being
told that it should recompute and install all packages, and their
dependencies, from @world as if the system were completely 'clean'. This
in turn requires that any 'pinned' versions are reinstalled as well. A
reinstall would mean uninstalling the currently installed package files
and replacing them with those from the new build. With 6.1.69 gone, this
isn't possible so portage complains.
It's the same problem you are having with nextcloud.
Adding these to "--exclude" means portage will not take them into
consideration when computing --emptytree and will leave them be as-is
without touching them. This will allow you to keep the 6.1.69 kernel,
and your existing nextcloud build.
Your nextcloud build 'might work' unless there's any significant
differences in use flags with the new profile that might lead to linked
library issues. You might have to find the hard way.
I too had an issue that was causing
sci-astronomy/calcmysky to fail when
rebuilding with the new profile (which was an upstream problem) and had
to force portage to ignore this and continue while I deal with it after
the fact (I ultimately had to wait for an version bump which was only a
minor inconvenience).
Hope this helps explain why you're facing the issue and why I think
--exclude might be your best option, especially if you _really_ want to
keep kernel 6.1.69.
Cheers,
Victor
signature.asc
Description: OpenPGP digital signature
