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

Bug#189370: acknowledged by developer (irrelevant)



From: Colin Walters <walters@debian.org>
Subject: Bug#189370: acknowledged by developer (irrelevant)
Date: 17 Apr 2003 21:56:00 -0400

> You don't understand Debconf.  It is a cache, not a registry.  I should
> be able to rm -rf /var/cache/debconf/config.dat *at any time*.  If I do
> that, since your question defaults to "yes", any local changes I've made
> will be destroyed.  

Of course I can understand that it is possible to destroy
local changes as I wrote in a former email.

> > Even if the default setting "true" might have slight possibilty 
> > to cause problem, "default" answer should be for majority users
> > and I think "true" is correct setting in real system.

It breaks Policy to some extent but follows it to some
extent, IMHO.

Former tetex packages provided language.dat as a
conffile so if one changed (manually!) it then one would 
be asked whether to replace it or not everytime at upgrading.

I changed it a configuration file which would be generated
in postints (of tetex-base) and adopted debconf so that
a user can select to modify it or not with debconf.

I believe the current handling of language.dat is much better
than the former one, at least, for normal users even now.

> > If this breaks Policy really I suspect Policy should be changed
> > in a more realistic way.
> 
> It does break policy.  There is no question.  And I think policy is
> correct.  If you don't think it is, the right way to solve the problem
> is to discuss the issue here on -devel.

I guess it depends on how to read Policy, in a sense.
For example, updmap was once a conffile and was in
/etc/texmf/dvips but the current teTeX upstream (so tetex
packages of Debian also) changed it completely and now
updmap is a normal script (in /usr/bin) and read configuration 
file /etc/texmf/updmap.cfg, that is, former updmap was
splitted into updmap and updmap.cfg.  Further its format
of configuration was changed completely.

Perhaps our handling at present will be not *perfectly*
compliant with Policy (I think it is compliant with Policy but,
at least, there are some who think not) but is there *perfect* 
way to handle this?

> Again, I am proposing a much more policy-compliant alternative that
> still provides most features; i.e. the way I do things with fontconfig. 
> I wrote a little bit about it in my first mail, but "apt-get source
> fontconfig" for the details.

Though I didn't check this yet but if I (or some other tetex 
members) can understand it and find it useful for us then
tetex packages will adopt it but if not (and if the current
handling really breaks Policy), is it the only way to get
back to the former scheme?

I have an impression that such Policy understanding prevents 
sane advance of packages.

Thanks,			2003-4-18(Fri)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <kohda@debian.org>
 Department of Math., Tokushima Univ.



Reply to: