Re: /opt [WAS: Re: New top-level dir]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/12/22 11:53, Zbigniew Jędrzejewski-Szmek wrote:
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.


Absolutely. I intended to thank you for bringing that behind-the-scenes grand plan up but seems it got lost in the edits. So thanks for bringing it up!

I actually do know the "factory reset" plan from way way back but had completely forgotten about it, and chances are I'm not alone in that. And I bet that not everybody in this discussion knew about it at all.

Others have complained about the lack of detail in the "benefit to Fedora" section, and I can only concur. At this point it's fairly obvious the change is just a tiny tiny part of a MUCH bigger agenda, and knowing and understanding the bigger agenda is necessary to make sense and valuate the proposal.

	- Panu -
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux