On Fri, Jan 14, 2022 at 3:51 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Fri, Jan 14, 2022 at 7:16 PM Colin Walters <walters(a)verbum.org> wrote:
>
>
>
> On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote:
>
> > The path "/usr/lib/sysimage/rpm" does look very out-of-place in
> > non-image-based systems, so *if* we want to move the rpmdb to a place
> > that's consistent across all our Editions, it should also be a
> > location name that makes sense across all Editions.
>
> I don't think we should discount alignment with OpenSUSE. When they originally
proposed /usr/lib/sysimage I started to write a bikeshed reply email (like many that have
been posted here) around why /usr/share was a bit better but then I said to myself:
"You know what? I don't care as long as we get it in /usr. Since they're
driving the change, and there really isn't any technical compelling reason to do
something else, it's fine."
>
> Also, proliferation of these paths has a cost; see e.g.
https://github.com/openSUSE/libsolv/pull/386
> Though in practice *most* cases will be fine just chasing a symlink from
/var/lib/rpm.
Wait, I thought this change was about making the path consistent
within Fedora variants?
CoreOS/Silverblue/Kinoite
ls -l /var/lib/rpm
lrwxrwxrwx. 1 root root 19 Dec 6 12:32 /var/lib/rpm -> ../../usr/share/rpm
$ ls -l /usr/share/rpm
total 52684
-rw-r--r--. 3 root root 53915648 Dec 31 1969 rpmdb.sqlite
-rw-r--r--. 5 root root 32768 Jan 14 18:10 rpmdb.sqlite-shm
-rw-r--r--. 1 root root 0 Jan 11 18:51 rpmdb.sqlite-wal
$ ls -l /usr/lib/sysimage/rpm
lrwxrwxrwx. 3 root root 15 Dec 6 12:23 /usr/lib/sysimage/rpm -> ../../share/rpm
This symlink is present on Silverblue but I don't see it on a stock
CoreOS image before it's been booted and subject to setup by ignition.
$ ls -l /var/lib/rpm -> ../../usr/share/rpm
I understand that converging on the same path as OpenSUSE makes
sense,
but does that mean we should not consider if there's a better
alternative? ...
I think it's fine to consider alternatives, but the tradeoff might be
that (open)SUSE sticks with what they've got. I have no idea but that
could be a question posed to them before deciding this.
And the "sysimage" path makes even less sense to me in the
OpenSUSE
context, since they don't have an OSTree based variant at all (unless
I am mistaken)?
Absent the rpmdb, and ignoring all other considerations like storage
and performance cost, could RPM learn to reconstruct the rpmdb? What
would it need locally to do that? Would it need to keep rpm package
headers and compare to what's installed? Some variation on rpm -Va?
The point would be to keep /var/lib/rpm/rpmdb* allow it to be
disposable, but with consequences. If rpm packages can be disembodied
from their payload, just leaving the metadata, seems like it's
plausible to reconstruct an rpmdb from checksums of what's installed
versus would could be installed. This raises questions like, garbage
collection of all these rpm files, would they be removed when the
package is removed?
--
Chris Murphy