On 3/19/21 8:16 PM, L A Walsh wrote:
On 2021/03/16 11:40, Andrei Borzenkov wrote:
And what exactly is not clear in this message? That my entire rpm database had been wiped and needed restoration from a user-backup to recover from suse-upgrade damage, again. Most users wouldn't have such a backup, so for most users, that would be an entire wipe.
Given the change happened a significant time ago and your the first to hit an issue and its regularly tested from a range of versions its hard to see most users being effected although most users are also now on btrfs and would have been able to roll back.
It's one reason why most of my scripts/programs take me so long these days, as 75-80% of the script is checking for error conditions and telling whoever is running the program (often me) how to fix it, cuz I don't remember every little detail when something breaks years later.
Now I don't know what I should do about this, since something will likely try to upgrade it again and will likely mess it up again.
Why did rpm have to change locations and source dialects and compression encoding? (all at the same time, from my perspective).
Compression because it saves time and money, both in package build times on the build farm and storage for mirrors. "Source Dialects" because sometimes RPM adds new features that make packaging easier and us packagers are a rather lazy bunch and like to take full advantage of them. Moving the database is mostly to help the people interested in transactional updates. Under the transactional update design the "Operating System" is placed on a read only filesystem where only the update mechanism can write to that filesystem during a transactional update. So that users / sysadmin's can still make configuration changes /etc becomes an overlay fs. /var also becomes a separate subvolume so that services can write to it. From this perspective the rpm database makes far more sense being on the read only filesystem with all the packages it installs. This is why you will also notice a pattern of packages moving there default config into /usr/share or /usr/etc and then allowing users / sysadmins to overwrite the defaults by writing to files in /etc. This has a side effect of making merging conflict files much easier because only values that have been overwritten need to be merged and unless something has been removed most will just stick to what the user configured. While such things aren't strictly needed in non transactional systems they don't generally hurt them and they are also useful in many cloud setups which is why you are seeing such changes being adopted by a number of distros. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B