On Mon, Jan 10, 2022 at 02:53:52PM -0700, Chris Murphy wrote:
On Mon, Jan 10, 2022 at 9:20 AM David Cantrell <dcantrell@xxxxxxxxxx> 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.
I've seen the rearranging the chairs comment in multiple locations now. If
the location doesn't matter, why can't the RPM db stay in /var/lib/rpm?
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.
To what degree do rpm and dnf intend to touch locations outside of
/usr *and care* about tracking those changes? 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.
These are valid points. My suggestion of /state (or another named top-level
directory...I saw /meta suggested somewhere, maybe LWN...but I kind of don't
want to imply references to Facebook) is on the basis of RPM operating with a
single database on a given system. The idea of multiple RPM databases is
interesting and I think there's value in discussing that, but that would be a
separate item for discussion.
Right now, a system needs to support installation from the vendor, third party
repos, and local system packages. All with a single RPM database. So I
suggested /state to get that information out of /var but still keep it tied to
the host in question.
The /opt tree introduces another wrinkle. It's one that's never really gained
a lot of use in the Linux world, but where it has it's been treated as both a
place where vendors can deliver software and a separate /usr/local. I think
it's reasonable to assume vendor-delivered things in /opt can be thought of as
more independent than what's in /usr, but that's just an assumption. My most
recent views of things found in /opt from third party vendors shows that they
are self-contained trees built with the mindset of "I don't trust what the
system will provide me".
To move the RPM database in to /usr for the rpm-ostree snapshot and rollback
case would also imply restrictions around what a user can and can't do with
RPM on their system. If that's the case, then I would say rpm should stop
being a general purpose tool for the user and become a backend only tool run
by the OS. Let the users create new third party packaging systems to install
things on their own system.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
