On 02/04/2024 04:51, John Covici wrote:
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".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?
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 causingsci-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
