This is a bit of tangent, but if I am not mistaken, I can create RPMs to
manage content of my home directory. How folks envision this would work
in the context of this proposal? But I also wonder if this is something
considered by e.g. systemd-homed.
I am asking this question, because move of the rpmdb into /usr is not
conceptual (and I admit that even in the light of my question above, the
/var is not really conceptual). So has anybody thought about more
generic concept for rpmdb, which would cover the mountable directories?
Vít
Dne 12. 01. 22 v 10:05 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Jan 10, 2022 at 02:53:52PM -0700, Chris Murphy wrote:
> 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?
We have three similar locations: /usr (system vendor tree),
/usr/local (admin non-packages installations), /opt (external vendor tree).
In other words, both /usr and /opt are for packages, but from different
sources. As an admin, you'd want to treat both package types the same,
and e.g. roll them back together. So having a separate tree for /opt
doesn't make much sense.
[At some point in the future] /opt should be renamed to /usr/opt and
symlinked for backwards compat.
> 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.
Yeah, /state doesn't help with anything. It'd be just some part of the
whole system state, without a clear separation of why this particular
subset. My preference: /usr/lib/sysimage/rpm > /var/lib/rpm > /state.
> To what degree do rpm and dnf intend to touch locations outside of
> /usr *and care* about tracking those changes?
Traditionally, packages installed all kinds of files all over the place.
But we're slowly and painfully moving towards the model where:
1. packages are only allowed to install under /usr, /var, and /etc.
(Or under /opt, but I'd want to move that to /usr/opt…)
2. packages must support /var/cache being wiped at any time, and
most packages support anything under /var being wiped at any time.
3. systemd and other projects are trying to only use /etc for local
admin state, and support "factory reset" by wiping /etc and /var.
So although rpm manages files under /var and /etc, it is not to the same
extent as /usr. In this light it makes a lot of sense to hold the
rpmdb state under /usr/ somewhere. The exact subdirectory doesn't really
matter, it's just a matter of convention, so obviously we want to follow
what opensuse and others are already using.
Zbyszek
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure