[Pkg-ltsp-devel] Re: local devices (i.e. usb sticks) with ltsp

[Vagrant Cascadian]

On Tue, Dec 12, 2006 at 07:28:03PM +0100, Oliver Grawert wrote:
> Am Samstag, den 09.12.2006, 17:24 -0800 schrieb Vagrant Cascadian:
> > On Sat, Dec 09, 2006 at 09:36:22AM -0800, Vagrant Cascadian wrote:
> > ok, well, i just changed the obvious policy violations and built a new
> > set of packages for debian:
> apparently we either have a different reading of the policy in debian vs
> ubuntu or its ok to change /etc/modules from a postinst, since its not a
> conffile and that seems to be the only case where editing files from a
> postinst seems to be explicitly forbidden. can you point me to the parts
> of the policy that point out why i'm not allowed to edit /etc/modules
> from a postinst script ? 

i'll do my best here :)

from debian-policy:

10.7.4. Sharing configuration files
...snip...
     If two or more packages use the same configuration file and it is
     reasonable for both to be installed at the same time, one of these
     packages must be defined as _owner_ of the configuration file, i.e.,
     it will be the package which handles that file as a configuration
     file.

     If it is desirable for two or more related packages to share a
     configuration file _and_ for all of the related packages to be able to
     modify that configuration file, then the following should be done:
     1.   One of the related packages (the "owning" package) will manage
          the configuration file with maintainer scripts as described in
          the previous section.
     2.   The owning package should also provide a program that the other
          packages may use to modify the configuration file.
     3.   The related packages must use the provided program to make any
          desired modifications to the configuration file.  They should
          either depend on the core package to guarantee that the
          configuration modifier program is available or accept gracefully
          that they cannot modify the configuration file if it is not.
          (This is in addition to the fact that the configuration file may
          not even be present in the latter scenario.)


note that point 3 uses "must", and specifies "configuration file", which
does not limit it to the scope of "conffile", even though packages are
not required to provide a tool for the editing the configuration file(s).

i think the release managers used this as the basis for the following
(much easier to read) release policy item:

http://release.debian.org/etch_rc_policy.txt

3. Configuration files

...snip...    

    Packages must not modify other packages' configuration files
    except by an agreed upon APIs (eg, a /usr/sbin/update-foo command).

so, in absence of a tool to modify configuration files, the
interpretation i read (and agree with) seems that you are not allowed to
modify a configuration file in the maintainer scripts.

beyond that, i think the intent of all this policy is so that installing
or removing one package will not break the operation of another. even if
that means it is much harder to automate some things.

i think another question to ask here is: which package owns
/etc/modules? it's certainly not ltspfsd.


this reminds me of a rather long (and somewhat confusing) thread
discussing a similar bug in lessdisks: http://bugs.debian.org/350407

Steve Langasek wrote:

"... You can't claim a well-known config file as yours just because there's
no other package on the system that has done so; this is still a policy
violation, both because it's not your config file to be editing, and
because your postinst script doesn't respect a user's config on upgrades
if the user has *removed* these update-lessdisk-kernels lines."

i think all of the above pretty much applies to ltspfs's maintainer
scripts.


another issue that i found in the ltspfs packages was a little more
straightforward:

10.7.3. Behavior
----------------

     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.

in ltspfsd.postinst, it blindly over-writes
/etc/udev/rules.d/88-ltsp.rules, without preserving any changes that
might be there, and ltspfsd.prerm removes the file on package removal.
i think this is actually better handled (and less code) by treating that
file as a conffile, which is what i did in my bzr branch.

while i can understand why you would want to remove this file (so
ltspfsd related udev events don't happen if ltspfsd is removed). i think
another policy-compliant way of getting that behavior should be
explored. is there a simple way for a block of udev rules to be only
considered if some other condition is met?

> (that code is going to be dropped from feisty anyway btw)

i am hopefull that we can continue to work in the same direction :)

live well,
  vagrant