On 3/24/21 3:15 PM, L A Walsh wrote:
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?
Yeah, its been the system default for ages now and most users don't change the defaults.
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.
Well it was changed for the same reason it's used :-) someone did the measurements and the newer form of compression that are only supported in the latest versions of rpm make smaller binaries and or decompress / compress data faster, at some point there was a thread on factory discussing this and showing some benchmarks so the change to the newer compression form was adopted, unfortunately significantly older forms of rpm don't support this but we made sure it worked in still supported distros.
"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.
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.
I don't believe we disabled any old syntax rather we added new syntax that older RPM versions don't understand. I'm guessing it can't be macros due to where and how it needs to be expanded for dependency generation (but I am not an expert in these specifics).
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. putting an overlay-fs over a frozen root doesn't mean /etc has to be moved.
Again i'm not an expert expert here but I know it was a design decision made because it makes life significantly easier in places (otherwise we wouldn't go to the significant effort of moving things).
/var also becomes a separate subvolume
/var already was a separate subvolume -- it was mean to be written to constantly (as in logs).
Yep and from this description you can start to see why it might not be the most appropriate place for storing the persistent state of the operating system which is basically what the rpm db is and why it might have been moved inside /usr which contains most of the persistent state of the OS that the db describes.
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.
At a guess because /usr/share should be reserved for system packages thta shouldn't be modified by sysadmins so I guess they have no reason to expect there to already be stuff there.
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.
Many of the common libraries that handle reading config files are now doing this at a library level which saves some work, but yes the people that care about this proposal are doing significant work to slowly adapt applications to handle 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.
I know these days we have a rescue system based off busybox but fortunately I've never had the need to use it maybe because on all the very rare times something has broken on my system i've been lazy and rolled back to the previous snapshot and waited for a fix before upgrading again. -- 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