Bug#596767: nfs-kernel-server does not check the ucf registry for conflicting package, registrations.
On 9/13/10 5:20 PM, Steve Langasek wrote:
severity 596767 wishlist
On Mon, Sep 13, 2010 at 02:38:25PM -0700, Dave Rawks wrote:
In the maintaner scripts included in nfs-kernel-server ucf is
used to detect whether the configfiles
managed by the scripts have been changed via a local edit. However the
postinst makes no inquiry against ucf
regarding whether another package has registered itself with any of the
files managed by nfs-kernel-server's
scripts. As such if another package ships for instance /etc/exports AND
also registers it's copy of the configfile
with ucf then subsequent calls to the "upgrade" section of
nfs-kernel-server's postinst script will result in
nfs-nerkel-server's default version of the configfile clobbering the
local copy even though ti is was
properly registered with ucf as belonging to the other package.
This situation can never arise among Debian packages, because Debian policy
stipulates that each configuration file has one and only one owning package.
Supporting this for the benefit of third-party or local packages sounds like
a wishlist bug to me.
Well, if the policy stipulates that only a single package can own a
config file but /etc/exports is neither listed in the conffiles for the
package AND it isn't registered with UCF then it seems that the package
is non-compliant with that exact policy. So fixing this is basic issue
of either properly owning or registering the file properly with the tool
used to manage the action of the maintainer scripts in accordance with
10.7.4 OR in the spirit of 10.7.3 nfs-kernel-server should only attempt
to place it's default config in /etc if there is no existing file
present. The default config provided by the package isn't "required for
the package to be sensibly configured" since it is fully compromised
entirely of commented out lines which provide documentation examples
which would be more suitably provided in the documentation for the package.
To presume unique ownership of a configfile, then to improperly mark it
as such, then to exercise a heavy handed overwrite only to provide
example comments, would all appear (to me at least) to be a stronger
contradiction with the policy manual and it's intent than my suggestion
that your package should play nice with third part and locally
Of course there is a reasonable middle ground also suggested in the
policy manual would be for the exportfs command provided by
nfs-kernel-server to provide some way to edit, via that tool,
/etc/exports in a manner that is persistent on disk.
To downgrade this report to "wishlist" status is either not well
intentioned or minimally provides that appearance in light of the above.