Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Hi,
to make it clear to everybody: The package that brought this up is
teTeX, but I think the point is more general
Thijs Kinkhorst <kink@squirrelmail.org> wrote:
> On Mon, 2005-10-31 at 18:56 +0100, Frank Küster wrote:
>> Because one of the changes in the new version was crucial for the
>> function of the program, the postinst script fails to initialize it, and
>> the whole installation process fails.
>
> Would it be possible to modify the program so that it is more robust
> with respect to this specific configuration setting? What kind of
> setting is it that causes the program to fail where a previous version
> appearently worked? It would sound to me like the solution that serves
> all in the best way.
It's an upstream change. In fact it has been several upstream changes
in several cases; most of the time they were either about renamed files
or variables, new directories were essential files are expected, or a
change in the TeX engine used for a particular format¹.
Of course it would be best to be simply more robust, but it's not always
possible. For example, in previous teTeX versions, the directories that
were searched for input files had a big, inconsistent, messy mixture of
names: TEXMFMAIN and TEXMFLOCAL, but VARTEXMF, and so on. Now upstream
has decided to rename them all, so that the names are TEXMFsomething.
These variables can be changed by a configuration file, and some of them
*must* be set. Now if a user refuses to accept the change that switches
from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer
work. There's no way around that except patching the upstream sources
to either revert the change, or look at both variables. Both would mean
to deviate considerably from upstream, without a perspective when this
could end, the latter would additionally mean heavy changes to the
source code.
I know that other packages had similar problems, and sometimes the
"solution" was to simply create a new package name, so that the user had
to explicitly install, e.g., apache2. In the case of apache the
additional benefit of this solution is that one can choose when to
switch, or to continue to use the old one. But for teTeX I don't think
that anybody would want to stick to the old.
Regards, Frank
¹if you don't understand that, forget it; it does not matter
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: