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

Bug#232990: tetex-extra fails postinst

reassign 232990 ptex-bin
retitle 232990 /etc/texmf/fmt.d/20ptex.cnf is handled wrong in maintainer scripts
severity 232990 serious

Dear maintainer of ptex-bin,

we got a bug report against tetex-bin and found out that in fact
tetex-bin's installation is broken because of ptex-bin's behavior. One
cannot install tetex-bin if ptex-bin was installed on the system, but
has been purged or removed in the meantime. This (and more, see below)
is why I set the severity to serious.

When ptex-bin is purged, it leaves over the file
/etc/texmf/fmt.d/20ptex.cnf on the system. This has the result that when
fmtutil is run to create (all or missing) formats, it will try to build
the ptex format, but fail. 

When ptex-bin is upgraded, it deletes the file in it's preinst script
(and creates it again from a template). This also deletes all changes
made by the user and violates policy which requires that any changes to
configuration files be preserved upon upgrade. (This would also justify
severity serious).

When ptex-bin is removed, but not purged, it also leaves the file on the
system. While this is in accordance with policy, it doesn't work with
current tetex because of fmtutils behavior as provided by upstream - the
problem is described above. For you as ptex-bin's maintainer, there are
two possibilities:

- rename the file upon removal so that it is no longer recognized, for
  example 20ptex.cnf.postrm-bak. This also preserves user's changes
  after removal.

- Or provide the file, but with only commented lines, and document this
  in README.Debian. The musixtex package does it like this.

Unfortunately, fixing this bug in new ptex-bin packages won't help us
tetex people out. The problem is that the bug is triggered if ptex-bin
has been installed, but currently is removed/purged. Therefore the user
also won't see fixed ptex-bin packages.

I suggest that we, the ptex-bin maintainer and the tetex-maintainers,
agree on a solution that will work if ptex-bin stays uninstalled and
also if it is installed again.

One possibility is that the file is renamed in ptex-bin, e.g. from
20ptex.cnf to 20ptex-bin.cnf. Then both tetex-* and ptex-bin can safely
delete the old file, and ptex-bin just uses the new one which is handled
correctly. An other way would be to try to find out during tetex-bin's
postinst whether ptex-bin is in fact installed and manipulate 20ptex.cnf
if it isn't. However, I fear this is less safe - we would have to make
sure that it will work in all combinations of upgrade, removal and
re-installation of the two packages. And there may be more pitfalls than
we can imagine currently.

For us tetex-maintainers alone, I admit, there's also something to do:

a) document this more clearly in README.Debian
b) try to make fmtutil more robust so that it doesn't fail with missing

Regards, Frank
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Reply to: