Re: CVS frank tetex-bin: replaced "exit 1" by a critical debconf note, debconf-updatepo
Hilmar Preusse <hille42@web.de> wrote:
> What does mean "critical debconf note" in this case?
essentially:
- exit 1
+ db_input critical tetx-bin/fmtutil-failed
+ db_go
> I've heard Adam Di Carlo complaining, that tetex-bin could reach the
> state ii without having all formats properly generated. Hence he
> became paranoid and started checking for special formats in his
> postin. Converting a failure into a note seems critical to me,
> exactly because of this.
Yes and no. Not that I'm happy with that solution. But I think if there
are bugs that prevent tetex from properly generating the formats, they
have to be fixed, instead of adding workarounds. And if there isn't a
bug to fix, but it's just a user who has messed up a system, then it's
also not arabtex's (or whatever Adam maintains) job to check for this.
> Packages (Build)-depending on tetex-bin
> should rely on having a working LaTeX, when tetex-bin is ii.
They should, but we can never really be sure. E.g. bugs[1] like
,----
| Fix permissions of the font cache directories, causing FTBFS of zope
| (and possibly others) (Closes: #267413, #267752), thanks to Pierre
| Machard <pmachard@debian.org> [frank]
`----
that prevent TeX from generating or finding the tfm files. Therefore the
change is only a quantitative one, not a qualitative, IMO.
> - Yes, it is acceptable as temporary solution, but we should revert
> that after sarge.
I think we should think of a really clean solution for conffiles of
teTeX, that also takes into account possible future changes and a way to
safely handle them. Then, the problem will be less severe.
But there's one feature of TeX that we will never overcome, I fear, and
that is the very close border, or rather a blurred no-man's-land,
between stuff that only a developer changes, and stuff that any user
would change. Thus, any user is able to cause the installation of teTeX
to fail with a simple file in /usr/local/share/texmf that looks
perfectly sensible to him.
And an other one, perhaps to be resolved in some future
exTeX or the like: That there are so many things hardcoded deeps in
TeX's basic. On a modern system, having to decide which languages will
be used in the future before "compilation", i.e. format generation, is
strange.
But yes, generally I agree to what you said, and am willing to revert
this post-sarge. OTOH, I don't want users with a f*cked up local
configuration to prevent tetex-bin from entering etch, or etch+1. I
hoped it would be easier to descriminate between real failures (which I
hope will simultaneously occur in many circumstances) and user
corruption, this way. And to downgrade bugs - which might not be so
true, or merely a question of how decided the teTeX team acts in such
cases.
Gruß, Frank
P.S. Viel Glück in München
[1] While we're at it: There should be a "thanks to Hilmar", too, in
this bug, but I had yet written the fixing changelog entry when you came
up with your analysis, and forgot to add you later
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: