On Wed, Jan 12, 2022 at 7:03 AM Colin Walters <walters@xxxxxxxxxx> 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 _______________________________________________ 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
