On Monday 21 November 2005 16:44, Goswin von Brederlow wrote:
> Frank Küster <frank@debian.org> writes:
> > Hi,
> >
> > on the debian-tetex-maint mailing list we often have problems to decide
> > which of the thousands of TeX input files should be treated as
> > configuration files - in principle, each of them can be changed in
> > order to change the behavior of the system. We are currently thinking
> > about a solution were there would be hardly any conffiles[1], but a
> > local admin could put copies of any file he likes into subdirectories
> > of /etc/texmf. This would shadow the dpkg-shipped file in
> > /usr/share/texmf and allow configuration. And of course we would
> > document this.
> >
> >
> > What do others think? Would it be acceptable Policy-wise to handle
> > configuration like this?
> >
> > Regards, Frank
>
> I think other packages have the same problem, gconf comes to mind, and
> they should sit together and work out a common solution.
Multi-level configuration is definately the way to go when possible IMHO
(this was also the conclusion reached at the CDD devcamp last spring).
gconf/gnome, KDE, XFCE, and any freedesktop-basedir-spec compliant system
already allow multilevel configuration stacking: each has a search path
which specifies the locations to look for any config key, for each config
key the search path is looked through and the first match is used (the
desktop-profiles package provides a general mechanism for managing the
search paths of the various DE's)
So you can for example have 4 config sets (each in its own location):
- one with the upstream default values
- one with overrides for upstream settings by maintainer
- one with cdd-overrides for the settings
- one with admin-overrides for the settings
Each party can then change his settings independently of the others,
overriding (only) the defaults they care about.
> > There is one major drawback, however: If a file that has a (changed)
> > copy in /etc/texmf is changed in the deb, the user gets no
> > notification. This is at least annoying - but on the other hand, many
> > users have newer or changed versions in /usr/local/share/texmf or in
> > $HOME/texmf, and they face the same problem.
> It would be nice to notify the user about changes in the default
> config and give the choice of a diff or 3 way merge. Maybe this is
> something that could be added to ucf (e.g. option
> --modified-file=/etc/texmf/foo) and then present the user with the
> same options and frontend as with normal config files.
If (as is the case for KDE, Gnome and XFCE) the granularity when combinying
the different configuration settings is per config-key and not config-file
any merge problems basically disappear: you just make sure you set the
search path to reflect the precedence among the various configuration sets,
any changes made by a party whose configuration settings have lower
precedence are then used transparently unless you've overriden that
specific setting.
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
Attachment:
pgppbBn9balFp.pgp
Description: PGP signature