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

Re: Bug#25428: autofs: autofs should check for presence of amd upon install

Wichert Akkerman writes ("Re: Bug#25428: autofs: autofs should check for presence of amd upon install"):
>Previously Richard Kaszeta wrote:
>> The postinst scripts for autofs and/or amd should attempt to address this
>> issue somehow.
>I strongly disagree. If you let both autofs and amd service the same
>mountpoint you have a configuration problem. Don't blame the package for
>a problem you create yourself.

The problem is that the autofs package makes a number of implicit
assumptions ('implicit' in this case meaning that the assumptions
aren't obvious until package installation)

1. That I would like to use nis automounter maps in addition to local
   maps provided in /etc/auto.master

2. That the nis automounter map I wish to use is entitled "auto.master"

The result of these assumptions on my system was some rather
significant breakage which should have been avoided.  I have a large
mixed-unix-system installation here, and packages shouldn't assume
that they know everything about my environment and intentions.

In contrast, the 'amd' package does not make such assumptions.  It
first queries whether I want maps locally or via nis, and if by nis,
the name of the map to use (all of these with reasonable defaults).
*Much* less likely to cause breakage (but unfortunately involves an
interactive postinst, which is a pain in itself).  Buto we can do
better than that.

Most packages seem to install in a minimal manner with a description
of how to further implement them.  An excellent example of this is the
NIS package.  Upon installation, just because you have a passwd map
available from your ypserver, it doesn't automatically assume you want
to add the +::::: entries to /etc/passwd.  'autofs' shouldn't make
assumptions like this either.

I would suggest a similar arrangment to the NIS package (minimal
install with clear documentation of further configuration) be adapted.

>I'm closing this bug.

Based upon my comments.  I suggest re-examining the issue.

Thanks for your time.

Richard W Kaszeta 			Graduate Student/Sysadmin
bofh@me.umn.edu				University of MN, ME Dept

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: