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

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

       For short, "compliant" may be equivalently used instad of "fully

       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

	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.

 "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: