On Tue, Jan 11, 2022 at 11:00:28AM +0200, Panu Matilainen wrote:
On 1/10/22 23:53, Chris Murphy wrote:
>On Mon, Jan 10, 2022 at 9:20 AM David Cantrell <dcantrell(a)redhat.com> wrote:
>>
>>On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote:
>>>https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
>>>
>>>== Summary ==
>>>Currently, the RPM databases is located in `/var`. Let's move it to
>>>`/usr`. The move is already under way in rpm-ostree-based
>>>installations, and in (open)SUSE.
>>>[snip]
>>
>>Moving the RPM database to /usr feels incorrect to me, but we should move it
>>to gain the improvements as noted in the feature proposal.
>
>Going back to the original discussions on moving rpmdb...
>
>Preferred is a new top-level location in /usr, .e.g /usr/sysimage/rpm.
>Next is "least worst" in /usr/lib/sysimage/rpm
>http://lists.rpm.org/pipermail/rpm-maint/2017-October/006764.html
>http://lists.rpm.org/pipermail/rpm-maint/2017-October/006722.html
>
>And the convergence was on /usr/lib/sysimage/rpm
>http://lists.rpm.org/pipermail/rpm-maint/2017-October/006785.html
>
>I don't see how /state solves the problem, rather than just
>rearranging the chairs.
The problem with /usr/something is that the rpmdb is not specific to
/usr contents at all, and unlike any other content in there, so
putting it there just *feels so wrong*. That's what /state or
/sysimage or, as we now have, /var supposedly solves.
+1
I thought I'd suggested something at / level back then (in
https://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html
and/or
https://lists.rpm.org/pipermail/rpm-maint/2017-October/006699.html)
but seems like memory is failing me :) Maybe I thought it would seem
too outrageous to FHS believers to bother.
The point was though, that the rpmdb is not at all the only data of
this kind and so having a dedicated home makes sense.
For many practical purposes it's probably just rearranging the chairs,
but a separate top-level directory describing the *system* state seems
instinctively *much* more correct solution to it than stuffing it
somewhere deep inside a loosely related fs.
Also +1
Just FWIW, I would quit my whining about this right there if it went
to a new toplevel directory instead because it just *feels* right
unlike /usr.
>>Numerous followups have noted the requirement that /usr contain read-only
>>content, that it be shareable across hosts, and similar concepts. While this
>>may or may not doable now like we could in the past, the bigger thing to me is
>>around the understanding of what /usr contains. It is generally understood
>>that /usr contains [most of] the installed system. What I think is a bigger
>>requirement or expection now is that one can tar up /usr and transport it to
>>another system or virtual machine or container and expect that it will
>>_probably_ work maybe with a bit of tinkering. This is a really valuable
>>thing to have for developers. Moving the RPM database to this tree adds a
>>component that is unnecessary and sort of out of place.
>
>Should /usr be independently portable? And is that with a version
>matched /opt, or can there be mix and match revisions of /usr and
>/opt?
>
>If /usr is to be truly portable and have e.g. 'rpm query, verify,
>remove, reinstall' work as expected, you need the metadata (the
>database) representing its state to always come along for the ride.
>Either the database is already in /usr, or you have to make sure /usr
>and /state are inseparable.
>
>If /usr and /state are inseparable, and if rpm can also describe
>anything in /etc or /var or /opt, then all or part of those
>directories are also inseparable from /state. And thus /usr. So I
>think /state doesn't help.
For one, /state (or whatever toplevel directory) allows for the fact
that there are write-operations to rpmdb that do not touch any
external files while maintaining read-only /usr. Such as rpmdb
--rebuilddb, or rpm --import.
And like mentioned in the original discussion and now here, although
the discussion is on rpmdb, it's not the only data of this kind.
Indeed. We have an opportunity here to get data that fits this categorization
in to a more correct location on the system. rpmdb is a big one, but
certainly not the only one.
>To what degree do rpm and dnf intend to touch locations outside
of
>/usr *and care* about tracking those changes?
I don't understand the question. Rpm tracks and cares about all
content it knows about equally, regardless of the path. /usr is NOT
special in any way to rpm, it's just that most of *distro* content
ends up in there but a huge number of packages have content spread
across /etc too.
Yes, the special semantics around /usr is from the rpm-ostree side and not
rpm.
>I think rpm can't remain
>static for all time. It either needs to become aware of multiple root
>trees, and even mix and match top-level directories to create variable
>roots. And possibly even manage these things. Or it needs to constrain
>its reach to /usr and /opt. Whether /usr and /opt are tied together,
>or can be mix and match with their own rpmdb's, I have no strong
>opinion on.
Oh, multiple rpmdbs. It's a while since that last turned up. It gets
tossed around as a solution but to me it looks like it brings more
problems than it solves.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT