Bug#638060: debian-policy: §9.1.1: FHS should also be a "must" for generated files
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:
>>>> I guess the concern is that you feel this language implies that packages
>>>> aren't allowed to support non-FHS configuration? Would this be better?
>>>>
>>>> The location of all files and directories must comply with the
>>>> Filesystem Hierarchy Standard (FHS), version 2.3, with the
>>>> exceptions noted below, and except where doing so would
>>>> violate other terms of Debian Policy or where the local
>>>> administrator has explicitly configured the software to use
>>>> different paths. The following exceptions to the FHS apply:
>>> With s/software/system/, sounds good to me.
>> That doesn't sound right to me. Surely the relevant configuration is
>> that of the individual software packages (setting DocumentRoot to /web,
>> setting TMPDIR when running some application to /tempfs/foo, or
>> changing Postfix's mail_spool_directory setting to /mail), not only
>> system-wide configuration?
> Those all sound like examples of configuring the system, except for
> TMPDIR which can be used as a run-time option and doesn't fit with
> what I usually think of as configuration[*].
Hm, okay. We seem to be using the same words to mean much different
things, since I think changing the Postfix mail_spool_directory setting is
configuring the Postfix software (since it doesn't affect anything other
than Postfix). Configuring the system would, to me, be doing something
that configures every software package on the system at once (like setting
TMPDIR globally for all processes), and there usually aren't as many hooks
to do that kind of thing.
> However: now that I've looked more carefully at the FHS, I see it
> explicitly makes statements like the following:
> /home is a fairly standard concept, but it is clearly a site-specific
> filesystem. [9] The setup will differ from host to host. Therefore, no
> program should rely on this location. [10]
> The constraints the FHS allows applications to rely on actually seem
> pretty conservative. Cases where they aren't are probably specification
> bugs and relying on the FHS means it is more likely that they can be
> found and fixed. I'd be fine with your original one-line change.
Right, the FHS doesn't tell software that it's not allowed to assume other
paths.
> [*] e.g., are one-off command-line options configuration?
Sure. You're configuring that invocation of the program to use
non-default behavior.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: