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

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



On Fri, 2003-04-18 at 00:08, Atsuhito Kohda wrote:

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

Ok, well, policy is quite clear this isn't allowed.

But let me say first that this is not to belittle your work on tetex;
I'm very glad you're working on it.

> 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.

But the dpkg prompt was there for a reason; to preserve user changes.

Your change may seem like an improvement, and in some ways it is.  But
again, using Debconf is not a license to overwrite the file.

> > 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.

"
11.7.3. Behavior
----------------

  Configuration file handling must conform to the following behavior:
    * local changes must be preserved during a package upgrade [...]"

Seems quite clear to me.  After that is a discussion about how to do
things correctly.

> 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.

I'm not sure how this updmap thing relates to what we're talking about. 

> 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?

Yes, there is.  See below:

> 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?

Well, it seems you're really not convinced Policy is being violated
here.  That's understandable I guess.  I am hoping other people here
will weigh in with their opinion.

Any policy editors?

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

Well, the solution might be to change policy.  In the interim, I think
my fontconfig approach is fairly good (although it certainly could be
improved).  That's why this thread is being CC'd to -devel, so we can
come to a consensus about this issue.  

Having some packages prompt for "manage with debconf" all in different
ways and with different warnings in the config files and different
defaults is most definitely a bad thing.



Reply to: