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

Re: Bug#189370: acknowledged by developer (irrelevant)



 On Thu, 24 Apr 2003 11:52:33 +0900 (JST), Atsuhito Kohda
 <kohda@pm.tokushima-u.ac.jp> said:

 >     the new mechanism might be okay if it first checks whether
 >     texmf.cnf is an admin's file or a file generated by update-texmf
 >     before generating texmf.cnf and overwrites it only in the case it
 >     was a file generated by the script (for example, with the way of
 >     update-modules).

On Wed, Apr 23, 2003 at 10:51:23PM -0500, Manoj Srivastava wrote:

 > 	Not quite. a) even if the file was generated by update-texmf,
 >  and the user modified it later, the user changes *must* be
 >  preserved. Secondly, You are missing the fact that you ought to ask
 >  if the user wants your new file or not. We can't just leave the user
 >  out in the cold if they have local modifications to the file.

 Here I have to disagree with you, if for no better reason than
 consistency.

 Look at the way update-modules works.  In the postinst, modutils does
 this:

 | CFGFILE="/etc/modules.conf"
 | ...
 | # If $CFGFILE exists and is not generated print a big fat
 | # warning and inform people about the new system
 | if [ -f $CFGFILE ] && ! head -1 $CFGFILE | grep -q "^$HEADER" ; then
 |         cat <<EOF
 | 
 | WARNING: you already have an $CFGFILE file which has not
 | been generated by update-modules. Debian now uses a new system which
 | uses multiple files in the /etc/modutils directory. See the manpage
 | for update-modules for more information on this setup.
 | 
 | Please check all changes you made in $CFGFILE and either
 | apply them to the provided files in /etc/modutils or add your own
 | files there. Then run update-modules.
 | 
 | EOF
 |         echo -n "Press [ENTER] to continue"
 |         read HITME
 | else
 |         update-modules
 | fi

 and looking at update-modules

 | checkoverwrite() {
 | 	local cfgfile="$1"
 | 
 | 	if [ -f "$cfgfile" ]; then
 | 		if ! sed -ne 1p "$cfgfile" | grep -q "^$HEADER" ; then
 | 			echo "Error: the current $cfgfile is not automatically generated." >&2
 | 			if [ -z "$force" ]; then
 | 				echo "Use \"update-modules force\" to force (re)generation."
 | 				exit 1
 | 			else
 | 				echo "force specified, (re)generating file anyway."
 | 			fi
 | 		fi
 | 	fi
 | }

 If a user happens to modify /etc/modules.conf (ignoring the comment at
 the top of the file), the next time update-modules is run (after
 updating modutils, or installing module packages), the changes will be
 lost.

 And we have lived happyly with that fact for about five years.

 In this respect, we are in fact incompatible with the rest of the Linux
 world, because /etc/modutils/ is a debianism.

 The user can prevent the changes from being thrown away by just
 deleting the header line.  In a sense, by leaving the header line
 there, the user has given permission to automatically overwrite that
 file.  It would be indeed better if update-modules used ucf to merge
 user modifications back in.

 > 	So no, I don't think the behaviour described above is
 >  optimal. 

 That I agree with.

 Marcelo



Reply to: