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

Re: preferred method for coexistence of debconf- and manual parts in conf[ig ]files?

On Wed, Nov 05, 2003 at 03:03:24PM +0100, Frank Küster wrote:
> if a package wants to use debconf to manage a configuration file, but
> still let the user have the option to manually add entries - is there a
> preferred way how to do this?

> The packages I have on my system (mostly woody, however) don't care at
> all about this and simply say "don't edit this file", except one:
> localeconf. However, there's a bug associated with that behavior,
> 172439 - but to be exactly the bug is about bad cooperation between
> localeconf and locales, not about the concept itself.

> Besides that, the localeconf method seems very good to me:

> Put the information from the debconf database into the file, but between
> markers ### begin DEBCONF section for $package...  ### end DEBCONF
> section for $package. So an admin can add his customization before or
> after that, and upon dpkg-reconfigure or an upgrade only the part
> between the markers will be changed. 

> Is this concept o.k.? I couldn't find anything in the policy about that.

It's a cop-out.  Policy implies that packages must allow administrators
to make arbitrary changes to config files, and not lose those local
changes.  People have bent the rules in the past, with varying degrees
of justification.  Most of these cases are abuses of the system and
should be considered policy violations.

> Here's why I come to ask the question: Recently, a bug was filed against
> tetex-bin, #209395, criticizing that a configuration file, language.dat,
> is not in /etc, but under /var. The reason why it was put there was that
> it was a generated file: Not user-editable, the only way was to run
> dpkg-reconfigure. A user that wants his own, manually edited file can
> still create it under /etc and divert the link that now points from
> /usr/share/texmf/tex/generic/config/language.dat to
> /var/lib/texmf/language.dat, so that it will point to his own file. He
> should have answered "no" to the question wether debconf should manage
> this file if he wants to do that. But it's not necessary for his setup
> to work - until he accidently accepts a change debconf proposes upon
> upgrade and wonders why it has no effect...

> The problem with that is, as pointed out in the bug report, is that now
> both the debconf database and language.dat are under /var, where backups
> are rarely done on homeusers systems, and he wants it under
> /etc.

Er, if you're not backing up /var/lib, that's your own damn fault.

Which is not to excuse the behavior of the tetex packages.  Those
packages are notorious for making a mess of config files; the latest
approach, claiming that these are not config files when they *are*
config files on every other TeX-using system in the world, is just the
latest embarrassment.  There's been plenty of argument over this, but
no one who could do the work to fully parse the config files seems
willing to spend the time on it.  (Personally, I don't have any use for
tetex at all -- I just regularly see the carnage on my build systems
because of build-deps.)

> I would prefer it to be under /etc also because it _is_ a configuration
> file, and thus it belongs there. But to preserve the possibility of
> local additions, I would like to find a way for co-existence of
> debconf-managed and manually-edited parts.

I would say that, even though this is a cop-out, it's a better solution
than what's in place for tetex today.

Steve Langasek
postmodern programmer

Attachment: pgpTXykdlnWzr.pgp
Description: PGP signature

Reply to: