On 9/13/10 5:20 PM, Steve Langasek wrote:
severity 596767 wishlist thanks 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 maintained packages.
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.
-Dave