Bug#209395: teTeX: language.dat mislinked
Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> wrote:
strangely, I didn't get your mail up to now, but saw it in the web
interface, by chance. Therefore the references aren't correct, I just
cut'n paste it.
Let me start with your end:
> Although I didn't investigated your proposal in details
> but I'm afraid if we put language.dat under /etc and modify
> it by a script then there could be breakage when a user
> modifies it in an unexpected way.
I hope to convince you that this is not the case with my script. On the
contrary, I am developing it because I believe that parsing and savely
modifying is the only way to avoid bugs, and even breakage. This is also
what debconf-devel(7) recommends.
Below comes some more reasoning about that, and then a technical
part. The technical questions might be interesting even to those who
don't like my approach.
> From: Hilmar Preusse <hille42@web.de>
> Subject: Bug#209395: teTeX: language.dat mislinked
> Date: Sun, 1 Feb 2004 16:34:39 +0100
>
> > > > language.dat is definitely a host specific configuration. If it
> > > > sits in /var it should be generated out of files sitting in /etc.
> > >
> > > So far I can remember, this is the Debian policy too:
>
> There are, perhaps (yes, it depends on what packages you
> installed), over 40 config directories (which containt more
> or less host specific configuration files) under /usr/share/texmf
> but I suspect some of them are not under /etc
This is true, we're not living in an ideal world. But that shouldn't
stop us from trying to improve the situation.
> I mildly think that we maintainers have right to decide which
> configuration files would be appropriate to be under /etc and
> so human editable or rather be appropriate to be generated
> automatically.
This is also right, as long as we _can_ decide. With language.dat,
however, it seems we cannot. For an average user, managing it with
debconf is a relief, they simply don't want to bother with its
syntax. However, if one of these average users happens to also use
swedish (just to give one example), he cannot rely on debconf alone, and
has to manually edit the file - but currently this means that he will
never be able to use debconf again, without destroying his
customization.
Thus there is not only the question where to put the file, but, more
importantly, how to handle it. And once we have established how to
handle it savely, there is no problem in trying to improve this
non-ideal world a little, by putting it where policy wants it.
Do you remember Bug #189370? It seems to be quite clear to me that
everybody but the tetex-maintainers regarded this as a policy violation
(and even you did some changes to config file handling to close it). And
I guess that means that even you had the feeling that it might be a
violation, only there was no good alternative. Others don't care whether
there's an alternative, and we will be getting such discussions on an
on, if we don't improve things.
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.
*****************************************************************
**** TECHNICHAL PART ****
*****************************************************************
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)?
Since we ask the debconf question in tetex-bin and have to fiddle around
with language.dat in tetex-bin's postinst, anyway, I would prefer to
simply remove that from tetex-base's postinst, if possible.
Here are some more technical remarks:
a) Currently, we move unused/old files to filename.dpkg-old in our
postinst scripts. This might be misleading, because the extension is
also used by dpkg for real conffiles - and that was it's original
use. Perhaps we could instead use postinst-old?
b) The postinst part of my new stuff is a lot of code and also a lot of
comments. To me, who didn't see it grow, postinst was complex and
quite hard to understand even before I added this (it is 249 lines of
code, 23 lines of comment, 16 blank). Therefore I had the idea of
splitting it in separate files. When postinst is executed, the
package is yet unpacked. Technically, we could move part of the code
to (non-executable, for lintian) scripts in
/usr/share/tetex-bin/postinst and only source them in the real
postinst.
After doing this, I hope the structure of the file is clearer, and
everybody can easily see _what_ is done. How it is done exactly can
then be seen and changed in the external files. I hope that this
could also make upgrades and maintainer changes easier and less
bug-prone.
Is this just ill-minded, or could it be an improvement?
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: