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

Bug#321257: tetex-base: Needs transitional code for 00updmap.cfg->10tetex-base.cfg



Package: tetex-base
Version: 3.0-6
Severity: normal

Currently, tex-common parses the configuration options from 00updmap.cfg
that it took over, and drops the rest into a file that tetex-base should
handle, but there is no code in tetex-base for that.

(Technically it may be easier to put the code into tex-common's
postinst, but it is clearly a tetex-base issue)

I tried to write a patch for this, but it isn't trivial.  There are a
couple of tasks to perform.  One complicating fact is that the order and
comments have changed, too, so that we cannot simply add or remove "#!"
signs, or complete entries, if we want dpkg to recognize the file as
unchanged if 00updmap.cfg was in fact unchanged.  

Using ucf might make things easier in this respect, however we must
somehow make sure that the entries for removed fonts and for fonts in
tetex-extra get removed, otherwise we'll get lots of failed postinst
bugs.  And if we simply present a diff to the user, this won't help him
much because of the large changes.

This is what needs to be done, AFAICS:

- cut out the entries (plus comments) that belong into 20tetex-extra.cfg

- Add the entries that are new

- Cut out (or comment) the entries that have been removed

- Transform the entries that have been transformed (e.g. antt now has
  lots of Map lines instead of only one, and a changed comment; lucidabr
  had two lines that were active, now there are four deactivated lines
  plus comments)

And all this while retaining user changes - for example, the old
tetex-base shipped:

# symbols for ConTeXt macro package
Map context.map

the new has 

# symbols for ConTeXt macro package
Map contnav.map

And if the user changed it to 

# symbols for ConTeXt macro package
#! Map context.map

then the postinst should transform it to

# symbols for ConTeXt macro package
#! Map contnav.map


Of course we can just forget that and say that it is a new file, and
that not taking over old changes in a *different* file does not violate
the must clause from Policy.  Together with README.Debian, NEWS.Debian
etc.pp. 

But I'd be happier with a nice solution that at least captures most of
the changes, and maybe somebody has a good idea.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer




Reply to: