On 2021/03/21 05:18, Simon Lees wrote:
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.
Most on brtfs?
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.
---- Asked why compression encoding was changed, not why compresssion is used. gzip and bzip2 were both supported previously. I might have even expected xz at some point, but I've seen no measurements on speed or %compression for one that went into rpm, nor have I seen anyone using it outside of rpm.
"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.
--- Try, but the new rpm doesn't have to disable the old syntax. OTOH, having new features doesn't need to sacrifice compatibility. The first versions of C++ were written as translators on top of other languages. I even remember one a RATFOR (Rational Fortran) of the first C++ standard. If that can be done, you can't tell me new feature sets have to be done in an incompatible way. I'm surprised the new features weren't implemented in rpm-macros. putting an overlay-fs over a frozen root doesn't mean /etc has to be moved.
/var also becomes a separate subvolume
/var already was a separate subvolume -- it was mean to be written to constantly (as in logs).
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.
Maybe. I can see some sense in that, however....
This is why you will also notice a pattern of packages moving there default config into /usr/share
/usr/share is already a separate file system in theory and practice. It contained arch-neutral data. That's one of the reasons my upgrade failed -- as the scripts didn't handle copies going to a pre-existing dir and merging -- they tried to 'mv' them.
or /usr/etc and then allowing users / sysadmins to overwrite the defaults by writing to files in /etc.
I'm far from convinced trying to move things out of /etc/, elsewhere is a good idea. I still think it is a bad idea in fact due to all the programs that reference /etc. It would be smarter to arrange some overlay on /etc that can automatically fall through to /usr/etc (or wherever) the base config may lie. I'm not sure the unionfs is there yet, but probably as much as brtfs was when you started using it.
This has a side effect of making merging conflict files much easier
Maybe once in place, but moving established systems to that point -- it would be nice if it was handled a bit more gracefully. But opensuse no longer has a fix-on-boot & continue recovery system which I'm more used to. Others may not notice the difference.