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

Bug#596767: nfs-kernel-server does not check the ucf registry for conflicting package, registrations.

On 09/13/2010 03:30 PM, Ben Hutchings wrote:
> On Mon, 2010-09-13 at 14:38 -0700, Dave Rawks wrote:
>> Package: nfs-kernel-server
>> Version: 1:1.1.2-6lenny2
>> Severity: important
>>         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.
> [...]
> It seems like we should register /etc/exports as belonging to
> nfs-kernel-server.  However, nfs-kernel-server will not be coinstallable
> with your other package since ucfr will fail.
> Ben.

Fair enough, however in the case that nfs-kernel-server detects that
another package has already registered /etc/exports it would seem
consistent to prompt for an interactive merge. Any presumption on the
part of the package that results in a locally managed config file being
overwritten without any prompt or warning is a pretty critical bug.
Especially in a server as core as nfs.

Additionally this type of situation should further support the cause
championed in bug #47773 against ucf
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477773). And then
alternate packages which ship a version of /etc/exports could utilize
diversion to prevent having their changes clobbered. It seems that this
bug has been marked as "will not fix" but there is no note in the bug
report that correlates with that state.


Reply to: