On Wed, Jan 12, 2022 at 11:24:49AM +0200, Panu Matilainen wrote: > On 1/12/22 11:05, 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. > > > >>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. > > Oh, right. More hidden agenda behind this thing. Panu, I hope you realize that I'm not connected to this change in any shape or fashion and I'm just commenting on the published proposal like the other participants in this thread. Zbyszek > When looking at it with > these glasses on, it explains quite a few things about the change proposal, > such as completely ignoring the fact that nearly all packages put something > in /etc. > > I'm not saying these are necessary bad goalsat all, it's just that there's a > huge disconnect between reality and the above model on which this change > seems based on, and not a single mention about these goals and changes > needed to get there. I mean, I totally get that you can't change everything > at once, but if there's a plan this big behind something then maybe it > should be brought up front, no? > > - Panu - > > > > >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. _______________________________________________ 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
