On 1/3/22 14:57, Lennart Poettering wrote:
On Mo, 03.01.22 11:57, Panu Matilainen (pmatilai(a)redhat.com) wrote:
> On 12/30/21 09:02, Chris Murphy wrote:
>> On Wed, Dec 29, 2021 at 8:19 AM Tom Hughes via devel
>> <devel(a)lists.fedoraproject.org> 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_la...
>>>
>>> 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 -