Re: Conffiles and possible conffiles
"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> wrote: > 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. This is essentially the same in a TeX system - the number of config sets is theoretically unlimited. >> 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. This is different in a TeX system: There is only one major configuration file, texmf.cnf, for which per-setting overrides work. In all other cases only one file is read; and in most of these cases this cannot be changed, because the files are simply TeX input files, and we cannot change TeX's behavior wrt to reading files. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Conffiles and possible conffiles
On Monday 21 November 2005 16:44, Goswin von Brederlow wrote: > Frank Küster <[EMAIL PROTECTED]> 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) pgpK7UVOT8ijI.pgp Description: PGP signature
Re: Conffiles and possible conffiles
Hi all, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Frank Küster <[EMAIL PROTECTED]> writes: >> 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. [...] >> 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. Indeed, it would be nice if there was *one* "Debian Way". I'm Cc'ing [EMAIL PROTECTED] to get its maintainer into the discussion - and ucf's because of your second proposal. Who else should be contacted? > 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. This sounds like a rather long-term thing. But on the other hand, it also seems to me as if it can be applied any time later even if we stop shipping arbitrary files as conffiles now, can't it? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Conffiles and possible conffiles
Frank Küster <[EMAIL PROTECTED]> 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. > > 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. > > 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. 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. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and possible conffiles
On Mon, Nov 21, 2005 at 11:31:22AM +0100, Frank K?ster wrote: > 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. In my opinion, kpathsea offer multi-level override and this is the best way to handle conffiles, so we should take advantage of it. This mean doing what you propose. This is the way Debian menu works: put menu entries in /usr/share/menu, allow the sysadmin to override them in /etc/menu and allow the user to override them in ~/.menu. If I were to redesign Debian/Unix from scratch, I would make 3-way override mandatory. So I think this is a great idea. I was on the verge of proposing that two year ago during the texmf.d flamefest but I though there was an unforeseen reason it could not work. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and possible conffiles
On Nov 21, Frank Küster <[EMAIL PROTECTED]> wrote: > What do others think? Would it be acceptable Policy-wise to handle > configuration like this? Yes. -- ciao, Marco signature.asc Description: Digital signature
