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

Re: Bug#231235: arabtex font installation is broken



Florent Rougon <f.rougon@free.fr> wrote:

I assume you didn't mean this as a personal mail, and answer on-list it
without deleting anything.

> frank@kuesterei.ch (Frank Küster) wrote:
>
>>> would be more robust... But it wouldn't work if the variable is set
>>> indirectly (like the HOMETEXMF = $HOME/texmf). 
>>
>> Which it usually is. This is why I didn't critizise the code - I don't
>> really have a good idea.
>
> Perhaps it is safer to drop the condition on texmf.cnf, then? Run
> mktexlsr and rebuild the format files whenever texconfig is executable
> and fmtutil.cnf is readable. ?
>
> This is more or less a question because it's been a loooong time since I
> last run texconfig. The fgrep on texmf.cnf is supposed, I think, to
> avoid wasting time if TEXMFMAIN points to something under /usr/local for
> instance. But running "texconfig init" in that case cannot hurt, can it?

I think it can't. And if it does, we have an other problem Eventually,
after the tetex packages have been correctly configured,
/usr/share/texmf _will_ be in in $TEXMFMAIN. If this would break
anything under /usr/local, we are in trouble (but I think we aren't,
we'd have heard about that yet).

>> But tetex-bin depends on tetex-base, and arabtex on tetex-bin. You might
>> say that arabtex shouldn't rely on tetex-bin's dependencies. That's
>> right, but then also it can't rely on tetex-base providing
>> 00updmap.cfg. If we (the tetex-maintainers) change one thing, we might
>> as well change the other. 
>
> I understand your point. Usually, the situation is clear: package B
> provides functionality b (and it is undisputed that only B provides this
> functionality). You need b and you happen to depend on package A which
> happens to depend on B. In this case, it would be clearly wrong (as a
> time bomb) for you to only depend on A.
>
> But in the case at hand, the functionality is not clearly provided by
> either tetex-base or tetex-bin, so the reasoning is not as convincing.
>
> However, my point of view is: OK, the functionality is distributed among
> tetex-base and tetex-bin. Then, I depend on both, to be sure. I think it
> has absolutely no cost, but ensures that tetex-base and tetex-bin are
> *configured* when a third party tetex package like arabtex is
> configured. Seems safer, without having to go hunting in the tetex-base
> postinst (which might change over time) trying to convice oneself that
> it will work even if tetex-base is configured later.

Yes, we should recommend this safer way, unless we have a clear
policy. And probably even then.

>> Perhaps we should really take up your proposal and write a tetex
>> policy. But first we should ask which changes Thomas Esser is planning
>> for next tetex...
>
> This would be a good thing. Unfortunately, I don't think I will have
> enough time this month to participate to the thinking and writing behind
> such a document. Maybe next month...

We can start thinking and discussing about it. But I don't expect that
we will be able to make an official policy for sarge, so we are not in a
hurry, really.

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



Reply to: