On Fri, Jan 14, 2022 at 3:51 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Fri, Jan 14, 2022 at 7:16 PM Colin Walters <walters@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
