profile migration stuck on binhost client

irets · Apprentice Joined: 17 Dec 2019 Posts: 228

I have a binhost chroot on my other system and a laptop which functions as a client.
The client has never compiled anything locally and has been 100% dependant on the binhost.

The binhost has already been migrated to default/linux/amd64/23.0/split-usr (stable) but my laptop is still on default/linux/amd64/17.1 (stable).

I'm following the upgrade instructions and the first step is to perform a full @world upgrade followed by a depclean but I cannot get past emerge --update --newuse --deep @world --with-bdeps=y --ask on my laptop (client).

pjp · Administrator Joined: 16 Apr 2002 Posts: 20476

I have a similar setup with a chroot binhost and a laptop client, but I haven't migrated yet.

If I understand what you've done, your chroot environment is on profile 23

irets · Apprentice Joined: 17 Dec 2019 Posts: 228

You are correct, I should have updated these both roughly at the same time but I wasn't thinking and now it's too late.

pjp · Administrator Joined: 16 Apr 2002 Posts: 20476

Ouch.

So when you normally do updates, you do know that the client should use the same ::gentoo repository and /etc/portage configuration as the chroot environemnt?

If the client and chroot are using the same ::gentoo repository, then I would do your normal emerge "update" command, excluding the binpkg options you normally use, but add the --pretend flag. The results should show what the client needs to be "current."

Knowing how much difference there is between the client and chroot is probably important.

Do you know when the last time the two were "in sync"?

If they weren't too far out of sync, maybe the laptop could build the packages. Or maybe the differences are small enough that you could risk switching the laptop to profile 23 and running the update.

I'm not recommending that at all, and it would be nice if someone with more knowledge happened along to offer guidance.

If you use IRC, you could check there. There might be a dev that could offer some feedback. Having the above information might be useful.
_________________
Quis separabit? Quo animo?

sam_ · Developer Joined: 14 Aug 2020 Posts: 1945

FWIW, we are working on improvements to Portage to help with keeping a binpkg consumer vs binpkg builder/provider in sync (bug 932739, bug 924772).

irets · Apprentice Joined: 17 Dec 2019 Posts: 228

pjp,

The binhost and client have around a 1-2 weeks of difference in their updates.

Here's the output of emerge --update --newuse --deep @world --with-bdeps=y --ask --pretend --getbinpkgonly=n --usepkg=n from the client.
It looks doable.
https://bpa.st/4QMA

Should I proceed with the transaction and compile the packages on my client?
That will lead to a situation where some packages are binary and some compiled locally but I don't know if that's a bad thing.

I use IRC but it can be a hit or miss.
I've had this problem for a while so I decided to post on the forums so that I don't have to keep checking my IRC client.

eschwartz · Developer Joined: 29 Oct 2023 Posts: 214

irets · Apprentice Joined: 17 Dec 2019 Posts: 228

pjp · Administrator Joined: 16 Apr 2002 Posts: 20476

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2170

irets · Apprentice Joined: 17 Dec 2019 Posts: 228

I synced my package.use/* & world files and after 23 hours and 54 minutes I passed a @world upgrade and a depclean on my client by compiling everything locally.

I will now proceed to follow the profile upgrade steps by continuing compiling everything locally up until step 16. when I'll pull a full system rebuild from my binhost.