Re: It's Huntin' Season
>>"Josip" == Josip Rodin <joy@cibalia.gkvk.hr> writes:
Hamish> That may be a mistake in policy then because in practice it is a must.
>>
>> You mean this should be an RC bug? Why?
Josip> This is actually an RC bug, because if one doesn't mark an
Josip> init.d script as conffile and doesn't install it manually from
Josip> postinst, they let dpkg happily overwrite it on each upgrade
Josip> and thus break the following rule:
>> Configuration file handling must conform to the following behavior:
>> * local changes must be preserved during a package upgrade, and
>> * configuration files must be preserved when the package is
>> removed, and only deleted when the package is purged.
This is a real bug in policy, and I'll file it as such.
>> Files under /etc/ that do not change program behaviour do not need to
>> preserve user changes, and there is nothing I can see in policy of the
>> FHS that says non configuration files can't live in /etc.
Josip> But FHS says:
Josip> 3.4 /etc : Host-specific system configuration
Josip> /etc contains configuration files and directories that
Josip> are specific to the current system.
Josip> You could interpret that as "it typically contains those" and
Josip> everything else is allowed, but then, what's the point in
Josip> creating a hierarchy if we're going to bump all sorts of
Josip> offtopic things everywhere because it's not explicitely
Josip> forbidden...
Sorry. The FHS does not go into the level of detail required
for it to be treated as an exhaustive specification fo the file
system. Look at this definition:
======================================================================
Filesystem Hierarchy Standard April 12, 2000
An implementation is fully compliant with this standard if every
requirement in this standard is met. Every file or directory which is
part of the implementation must be physically located as specified in
this document. If the contents of a file are described here the actual
contents must correspond to the description. The implementation must
also attempt to find any files or directories, even those external to
itself, primarily or exclusively in the location specified in this
standard.
For short, "compliant" may be equivalently used instad of "fully
compliant".
An implementation is fully compatible with this standard if every file
or directory which it contains can be found by looking in the location
specified here and will be found with the contents as specified here,
even if that is not the primary or physical location of the file or
directory in question. The implementation must, when it attempts to
find any files or directories which are not part of it, do so in the
location specified in this standard, though it may also attempt to find
it in other (non-standard) locations.
For short, "compatible" may be equivalently used instad of "fully
compatible".
======================================================================
So, having a README file, or a file not specific to the system
itself (well, NIS, bind, etc arguably affect more than this system,
but that is nit picking) would not make the system non-cmpliant.
And Debian policy merely states that conformance is a
desirable goal; and in no way states that we should be more
aggressive than the FHS itself.
manoj
--
"Fortunately, I keep my feathers numbered, for just such an
emergency." Foghorn Leghorn
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: