Bug#209395: teTeX: language.dat mislinked
Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> schrieb:
> From: frank@kuesterei.ch (Frank Küster)
> Subject: Bug#209395: teTeX: language.dat mislinked
> Date: Tue, 03 Feb 2004 14:21:06 +0100
>
>> This would be o.k. if there was no other way (because priority is that
>> the package works, and installs smoothly for most users, not that it
>> follows policy letter by letter). But look - there is a way. Or will be
>> - I'm nearly ready.
>
> Sounds great.
Well, here it is.
>> Currently I have one problem with my script and that is that
>> language.dat handling is doubled: Both tetex-base's and tetex-bin's
>> postinst scripts copy /usr/share/tetex-base/language.dflt to
>> /var/lib/texmf/language.dat. Does anybody know a specific reason why
>> this should be done in tetex-base (e.g. because some packages depend on
>> tetex-base and an existing language.dat, but not on tetex-bin)?
This is not yet resolved (and leads to undesired behavior of "my"
postinst when upgrading or installing). I would like to hear a comment -
should I drop it from tetex-base.postinst?
>
>> Here are some more technical remarks:
>>
>> Is this just ill-minded, or could it be an improvement?
>
> I'd like to hear a comment from other members.
Me, too.
So here comes my stuff. The patch I propose is not very complicated, I
hope, but still rather long. I have commented the details in the file,
but to make it easier to understand how it goes together, here is the
flow:
A. handling of language.dat in config
1. First we ask whether debconf should bother with language.dat at
all, as before. If no, config does nothing.
2. If yes, config looks for an existing language.dat. If it finds
one, it looks for every hyphenation pattern that it knows about
and checks whether it is commented out or active. Active patterns
are stored in a variable
3. This variable is merged with the new defaults (currently, french,
ngerman) if the existing language.dat is old "enough", and the
value is stored in debconf.
This means that the values used before the upgrade are now in
debconf, irrespective of whether they were activated by debconf or
manually.
4. The debconf question is asked, the updated value is saved in
debconf.
Of course the question is not asked if it's just an upgrade and our
show_old stuff doesn't apply. No problem - just no changes.
B. handling of language.dat in postinst
1. We check if we manage language.dat
2. If yes, we repeat looking for an existing one (didn't want to
bloat the debconf database with such information). If there's
none, we simply copy the default one to /etc/texmf/language.dat.
If there is one, we first ensure that every pattern that can be
managed by debconf is indeed mentioned in the file, either active
or commented-out\footnote{This will almost everytime be the case
anyway. But we want to be really sure}. Second, we comment out
_all_ debconf-managed patterns for the moment. Remember, the
information, which were active before, is in the database. And
since there is no explicit information which were not active, this
is the easiest way to make it possible to remove unneeded
patterns.
This is done in the shell functions sanitize_ldat (add missing
patterns) and allcomment_ldat (commenting out).
3. Now, if necessary, we move the manipulated file to the place where
it will be looked for in the future, /etc/texmf/language.dat.
4. Then we read the debconf information and uncomment all selected
patterns, as in 2.0.2-6.
I think this approach is save, it allows the user to combine
dpkg-reconfigure and manual interaction in arbitrary order, it preserves
changes on upgrade, and last and least language.dat can be under
/etc.
Additionally, there are small patches to the templates file and
tetex-base's prerm - we forgot to remove the symlink.
I have tested the packages in the following way:
- upgrading from woody to sid (problem copies its language.dflt and
makes the link)
- upgrading from woody to sid, but with tetex-base upgraded separately,
removing of /var/lib/texmf/language.dat and the symlink, then
tetex-bin
- fresh install on sid (same problem as above)
- upgrading from unstable tetex-bin to new unstable tetex-bin, i.e. from
tetex-bin_2.0.2-5.1 to tetex-bin_2.0.2-6.1 (my private versioning for
the test packages, will never get out of here)
- many dpkg-reconfigure runs with editing of /etc/texmf/language.dat in
between, using weird comment signs etc, both on sid and on my
woody/bunk-2/private_backports workstation.
In all cases, config and postinst behave as we want: Preserve user
changes (or rather copy them to the debconf dialog), include debconf
changes.
Regards, Frank
P.S. In a discussion with my application manager, I just learned that
the version numbers we use for tetex aren't so clever. Debian revisions
with minor numbers, like tetex-base_2.0.2-5.1 or tetex-bin_2.0.2-4.2,
are usually meant to be used for NMUs. While a NMU for tetex-base is
quite improbable, an upload of tetex-bin by the security team or (as a
binary-NMU) by a porter for some particular architecture might well
occur sometimes. So we should avoid these numbers in the future, I
guess. Well, we'll be getting really high in Debian revisions, but
that's not a problem.
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: