On Wed, Jan 12, 2022 at 7:03 AM Colin Walters <walters(a)verbum.org> wrote:
On Wed, Jan 12, 2022, at 4:05 AM, Zbigniew Jędrzejewski-Szmek wrote:
> 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.
Unfortunately, real world RPMs that install into /opt also have e.g. log files in
/opt/somesoftware/log, not /var/log/somesoftware. So it can't be underneath the
read-only /usr mount. This is why rpm-ostree just straight up rejects RPMs that install
into /opt.
https://github.com/coreos/rpm-ostree/issues/233
The FHS says /opt is for static files. I think logs going in /opt is
asking for trouble if you really care about your logs. I'm not super
attached to enforcing /var/opt/<provider>/log versus dumping it in
/var/log. I think I prefer the latter because it's consistent with
/etc/opt/<provider>/ and is thus consistent. If you opt-in to /opt
then you don't get to opt-out of all the opt's. (not the best pun)
I think I agree with Chris that really what we want is a separate
rpmdb for this. That would mean these packages don't participate in offline
transactional updates, can't be rolled back etc.
Maybe we could. If /opt is on a subvolume (of some kind) with its own
rpmdb, it can be snapshot, update the *snapshot* rather than the
currently active subvolume. Once update completes, snapshot it again -
even could be read-only like /usr. Even could get signed with fsverity
before it's made active. Oops the update broke things, let's just roll
back /opt. But there are some nuances here I'm not sure about, like
maybe you'd want to split up the updates such that you're not
simultaneously updating /usr and /opt - maybe they should happen in
separate transactions? *shrug*
I think (open)SUSE's proposed Btrfs subvolume layout for transactional
updates is going to put /opt into /var - so /var/opt includes the
static files.
--
Chris Murphy