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

Bug#638060: debian-policy: §9.1.1: FHS should also be a "must" for generated files



"Bernhard R. Link" <brlink@debian.org> writes:
> * Russ Allbery <rra@debian.org> [120227 19:03]:

>> Could you be more specific about exactly what behavior you're worried
>> about?  I thought about this for a while before making this change and
>> can't think of any place where this would realistically affect
>> packages.

>> Note also that Policy is specifically Policy *for Debian packages*, so
>> we don't need to worry that Policy imposes restrictions on what admins
>> do.  It can't; that's out of scope.

> I guess it could be misunderstood about what kind of files and
> directories a package may expect: If a package deletes all top-level
> directories not allowed by FHS or mentioned by Debian policy, is that
> a violation?

As a general rule of thumb, we don't bother to explicitly rule out all of
the bad things you *could* do.  Policy also doesn't say that software
shouldn't cause physical damage to the system hardware or delete user home
directories; we expect people to use some degree of common sense.  It
takes a lot of time and energy to try to write down such rules, and I
think that time is generally better spent spelling out what to do in cases
where there are multiple possible reasonable answers.

> If a package fails to work with home directories in /user or a package
> fails to work with TMPDIR=/tempshares/username, is that a bug in the
> package?  The answers to all those questions should be obvious, but as
> people like to make policy more explicit and less interpreted with
> common sense, it might be good to be more explicit about that.

The problem with attempting to nail all this down for the FHS is that one
weakens the FHS requirement in ways that can be tempting for package
maintainers to use, but we normally want package maintainers to focus on
making the software work with FHS paths and put files in appropriate
locations and working with specially-configured non-FHS paths is more of
an additional feature than core expected package behavior.

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:

I just want to make sure that we don't trade a real problem with the
current language (the FHS obviously does not apply only to files installed
by Debian packages; it also applies to things like PID files, mail spool
files, etc.) for a theoretical problem.  But of course I wrote the
language, so I obviously think it's clear.  :)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: