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

Re: Bug#150514: Uer maodifications _must_ bre preserved, even is a co-admin said otherwise a few releases ago

On Mon, Jun 24, 2002 at 04:18:42PM -0500, Steve Greenland wrote:
> On 24-Jun-02, 14:53 (CDT), Gordon Russell <gor@dcs.napier.ac.uk> wrote: 
> > On Mon, Jun 24, 2002 at 01:57:36PM -0500, srivasta@acm.org wrote:
> > > 	But you don't. You retrieve the information from debconf,
> > > 	where it had been set at some point in the potentially remote
> > >  past by someone else. Had you been asking everytime, this would not
> > >  be an issue.

> > Yes I agree that this seems in breach of Policy. The Policy also goes
> > on to say something about not asking questions on an upgrade. I disagree
> > with your philosophy that debian=multi-user and thus system administration
> > is an uncontrolled multi-user activity. This is not sensible as a procedure,

> Wrong. Regardless of your opinion of other people's administration
> procedures, if you overwrite a user modified file under /etc/ without
> asking you are in violation of policy, and it is basically unacceptable.
> I'll offer one exception: if the file is very clearly marked as being
> overwritable, and is offers a clear, easy way to remove the
> possibility of being automatically modified, then I think that's a
> generally accepted procedure:

>     # This file is currently being re-generated from the answers stored in
>     # debconf. If you modify this file directly, your changes will be
>     # overwritten unless you remove the line containing I_BELONG_TO_DEBCONF.

Since this is in reference to update-modules, I'll point out a couple of
facts that I don't think have been given much weight in the debate.

From the top of the generated /etc/modules.conf:

### This file is automatically generated by update-modules"
# Please do not edit this file directly. If you want to change or add
# anything please take a look at the files in /etc/modutils and read
# the manpage for update-modules.

And, from the manpage for update-modules:

       force  update-modules   checks  if  the  current  /etc/mod­
              ules.conf and /etc/chandev.conf are generated files
              by checking for a special tag on the first line. If
              this tag is not found  generation  is  aborted.  By
              supplying  force  as  parameter  only  a warning is

In other words, there is a very clear mechanism by which administrators
can ensure their local changes to /etc/modules.conf are preserved:
delete the first line of the file.  Which seems pretty obvious to me,
since I wouldn't leave a comment in saying the file is automatically
generated if it isn't; but it apparently isn't obvious enough, for there
to be such outcry regarding the use of update-modules.

If the mechanism by which update-modules preserves local changes needs to
be better documented, perhaps by in-line documentation in modules.conf
itself, so be it -- but expecting maintainers of all module-containing
packages to prompt whether to overwrite is going to get real old, real
fast. :P

When Manoj was positing on IRC, the idea came up of using ucf to manage
/etc/modules.conf.  If that could be used to successfully determine
whether the user has made local changes without modifying the first
line, I think that's a great idea.  Then only the people making
boneheaded changes need be prompted -- everyone else has already clearly
declared their preference (by not making changes or by making local
changes in the documented manner), and can be spared the tedious debconf

Steve Langasek
postmodern programmer

Attachment: pgpB8jTK8B3Eg.pgp
Description: PGP signature

Reply to: