rpm 4.13.0 should require newer libcx

[Lewis Rosenthal]

Updating rpm 4.8.1 to 4.13.0 poses a problem, because apparently, the spec only requires "libc" and "libcx" without specifying a minimum version (according to rpm -q --requires). This leads to a broken rpm upon updating:

POPUPLOG.OS2:

X:\USR\BIN\RPM.EXE
RPMI07->LIBCX0._fread
127

We see this with an update all on a fresh ArcaOS install, and I got it when attempting to just update os2-base (and its dependencies).

[Lewis Rosenthal]

Workaround is to manually copy latest libc066.dll and libcx0.dll after unlocking existing copies, reboot, and then update all. It's not pretty.

[Lewis Rosenthal]

I should add that for update all, as long as libc and libcx are being updated in the batch, a reboot resolves the rpm failure, however, when nothing is requesting an update to libc and/or libcx, a reboot will not recover from the condition, and rpm will continue to fail.

When rpm fails like this, running yum from the command line simply returns to the prompt with nothing (except another POPUPLOG.OS2 entry as above). ANPM throws an error, but the package lists remain empty (naturally, as this content is provided by yum, and when yum can't run, we get empty package list windows).

[dmik]

Lewis, yes, this is a global problem. See #259. We can solve it manually each time by adding libcx >= x.y.z (and we in fact already do it in several places) but this error, as you may already guess, is error prone. For now, let's make update all a requirement. I mean, we should advertise aggressively that the first thing a user should do is anpm/yum update all if they run in any kind of problem.

[dmik]

Forgot to say that teaching users to do update all is a good practice even if/when we solve #259 — there are many more cases when auto-dependencies won't always work correctly.

[Lewis Rosenthal]

I hate to disagree, Dmitriy, but in our experience, update all is far more dangerous than updating critical components (libc and libcx, os2-*, and rpm, yum, and Python) first, and then updating the rest. It is not uncommon for users to go weeks or months (or even years) between updates, and update all can — and does — lead to unpredictable conflicts.

Related to this ticket, update all clearly broke a test system, leaving it in an inconsistent state, where libc and libcx were not able to be updated. We got part way into an update all and rpm failed to run, leaving half the updates undone.

We have updated the ANPM best practices wiki, however, to list updates to libc and libcx first, then os2-*, followed by rpm, yum, and Python, and then everything else.

In your ticket:259#comment:1, you mention that specifying minimum requirements is error prone. I'm not sure I understand the issue which would preclude a tweak to the rpm spec to ensure that libc and libcx packages were at the required minimum levels, until such time as rpm were smart enough to test the installed dlls directly for required exports.

If this is something which definitely will not be addressed in such a tweak to the spec, then we can close this as won't fix. Hopefully, it can be mitigated by judicious update ordering and a later improvement to rpm.

[dmik]

Okay, I see your point. But the thing is that an update all getting screwed is even worse than this ticket's issue. It should be addressed in the first place then. It's not up to the user to decide upon the order in which they install packages — this beats the whole purpose of a smart package manager. This definitely deserves a separate ticket, created #260 for that.

Regarding #259 and error-proneness. By that I mean that it's easy to forget to add the exact version number of a particular DLL to the spec file, especially if there are a many DLLs getting forward-incompatible updates and/or many packages getting dependent on these updates. Regarding this particular case, I'm afraid I have to add a specific version dependency manually this time as #259 is not yet there and as update all isn't always reliable. Just keep in mind that even with these manually fine-tuned dependencies we don't solve a generic problem described in #260.

[dmik]

A new RPM with a hard coded dependency to LIBCx 0.5.3 is uploaded to exp. Please test and if it's fine I will move it to rel.

[Lewis Rosenthal]

Thanks for this, Dmitriy. Email sent to the AN testers' list to try to get as much feedback as possible as quickly as possible.