On 1/3/22 14:57, Lennart Poettering wrote:
On Mo, 03.01.22 11:57, Panu Matilainen (pmatilai@xxxxxxxxxx) wrote:
On 12/30/21 09:02, Chris Murphy wrote:
On Wed, Dec 29, 2021 at 8:19 AM Tom Hughes via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
I don't see how this is FHS compliant, which in turn would make
it non-compliant with Fedora Packaging Guidelines, namely:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_filesystem_layout
The FHS describes /usr here:
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html#purpose18
as "/usr is shareable, read-only data" which clearly does not
apply to a database that changes.
In practice it is read-only data, except when software is being
installed or updated. The FHS is a PITA sometimes, but it's not
advocating for systems that can't be updated or changed..
The rpmdb has traditionally been like that, but it doesn't mean it will stay
that way forever more. There are all manner of currently unimplemented
use-cases which would require changing the database outside a direct
install/update/erase context. Many of those use-cases are related to files
and would fall under "but you need writable fs for that anyway" but not all.
Of course it'll always be *mostly* read-only data because of the nature of
the data, compared to a general purpose db in /var.
Can you provide an example for such feature requests? i.e. where the
rpmdb should be writable even though /usr is assumed to be immutable?
There seems to be this strange underlying assumption that all packaged
content lives in /usr when that's not at all the case. To install a
kernel, or a config-only package (under etc), or 3rd party software
putting stuff under /opt, or... you need a writable rpmdb. Ditto for
'rpm --import'.
But the kind of thing I had in mind when making that comment initially
is eg ability to update file states in the rpmdb to reflect local
changes from eg network mounting .. well, the typical example would be
/usr but in this case that gets a little strange.
In general, "data set by users" is the common case, whether a policy to
flag a given package as unremovable or non-updatable, or add a "reason"
(dependency or user-installed), or other annotations.
- 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
