[SOLVED] Made a libcrypt upgrade mistake... what next?

[pjp]

I wasn't intending to perform the upgrade and missed adding the --ask option to the "most common issue."

[Josef.95]

Adding virtual/libcrypt:0/1 in package.mask should probably help.
(This should prevent the downgrade)

[pjp]

Thanks. That and reissuing the previously referenced command seems to produce results that look reasonable to me

Since this is a stable upgrade, is this "normal"? I understand this is a unique situation, but the blocker and then having to mask a virtual seems strange, so I want to be sure that nothing seems problematic (partly because my other system has a conflict between news items, but this process may resolve it.)

[sam_]

I'd say it's not normal to have the blocker appear but it's not unexpected either (I describe this scenario here).

It's often, but not always, helped to mask the older subslot so I was on the fence about whether I should do it globally (I didn't want it to lead to more confusion if it didn't work). I'd now say it's worth us doing it at this point given it can help (done here).

The blocker, for what it's worth, is valid. glibc[crypt] and libxcrypt[system] really do block each other and install colliding files. The issue is that Portage should realise it can upgrade all consumers of virtual/libcrypt and therefore nothing should be holding onto virtual/libcrypt:0/1 (which asks for glibc[crypt]). Most of the time, it does! But not always, apparently. (Explaining in detail because I suspect I'll end up linking to this thread again.)

The output isn't available in this thread for me to explain the issue a bit more but the example output under 'last resort' on the wiki should explain it. In that output, you can see Portage for some reason thinks it can't rebuild e.g. util-linux, even though it can (it's already recognised it should rebuild e.g. mailutils there!). --ignore-built-slot-operator-deps=y tells it to ignore the already-built-against-subslot and just rebuild anyway without trying to hold on to the existing one. It should not be needed, but it is sometimes.

It seems like adding the "mask previous subslot" tactic is necessary even with that option though in some cases .

(I've updated the news item with a reference to unmasking :0/1 if people want to postpone the upgrade, but I don't recommend doing this.)

TL;DR: The news item was missing a step which hopefully would've able to help you in this case by using the sledgehammer --ignore* option, but I've now masked virtual/libcrypt:0/1 to help dependency calculations as it's helped some people (it's just not a silver bullet).

I do apologise for the inconvenience. This is one of those things which we put off for essentially as long as possible while we figured out a practical plan, but not something we had complete control over given it's an external event (glibc dropping libcrypt support - we're not jumping on this, it's been on the agenda for a while).

[pjp]

Thanks sam_. I was primarily wanting to make sure my mistake didn't cause any problems for the upgrade.

As all upgrades are an inconvenience :), I very much appreciate the news item which reflected the potential impact, and of course the efforts toward testing. I by no means expect upgrades, especially complicated ones, to be friction free.

When I complete this system, I'll update the repo on my other one to see where it is, but I suspect I'll have another thread for that issue.
_________________
Quis separabit? Quo animo?

[pjp]

Following up to close this.

The update completed without issue.


The second system I mentioned did not have a conflict with the "Possible failure to preserve libraries" issue. I had a masked package and two others that were no longer in the gentoo repository. After addressing those issues, I had to use the "nudge" command and the upgrade completed.

Thanks again everyone!
_________________
Quis separabit? Quo animo?