[tex-live] [pretest] pdfcsplain is bad linked in x86_64-linux

[Zdenek Wagner]

Yes, I have it right in my build. The symlinks are created by the texlinks
script invoked bu the run-texlinks target. The script reads fmtutil.cnf.
Thus the only change I made before building is:

$ svn di Build/source/
Index: Build/source/texk/texlive/tl_scripts/fmtutil.cnf
===================================================================
--- Build/source/texk/texlive/tl_scripts/fmtutil.cnf    (revision 33898)
+++ Build/source/texk/texlive/tl_scripts/fmtutil.cnf    (working copy)
@@ -56,9 +56,9 @@
 #
 # from csplain:
 csplain pdftex - -etex -enc csplain-utf8.ini
-pdfcsplain pdftex - -etex -enc csplain-utf8.ini
 pdfcsplain xetex - -etex csplain.ini
 pdfcsplain luatex - -etex csplain.ini
+pdfcsplain pdftex - -etex -enc csplain-utf8.ini
 #
 # from eplain:
 eplain pdftex language.dat -translate-file=cp227.tcx *eplain.ini

Thus the order in fmtutil.cnf is the key to the problem. And why the
problem did not occur in TL 2013? I can even explain this mystery. The
reason is that pdfcsplain for xetex and luatex was missing in TL 2013
pretest, these formats were added later after all binaries as well as the
symlinks were created.


2014-05-07 21:14 GMT+02:00 Zdenek Wagner <zdenek.wagner at gmail.com>:

> 2014-05-07 21:03 GMT+02:00 Reinhard Kotucha <reinhard.kotucha at web.de>:
>
> On 2014-05-07 at 19:27:45 +0200, Petr Olsak wrote:
>>
>>  > On Wed, 7 May 2014, Reinhard Kotucha wrote:
>>  >
>>  > > I vaguely remember that the symlinks are created by fmtutil.  If
>> true,
>>  > > probably the order has to be changed in fmtutil.cnf:
>>  > >
>>  > > It currently is:
>>  > >
>>  > >  csplain pdftex - -etex -enc csplain-utf8.ini
>>  > >  pdfcsplain pdftex - -etex -enc csplain-utf8.ini
>>  > >  pdfcsplain xetex - -etex csplain.ini
>>  > >  pdfcsplain luatex - -etex csplain.ini
>>  > >
>>  > > Could you try
>>  > >
>>  > >  csplain pdftex - -etex -enc csplain-utf8.ini
>>  > >  pdfcsplain xetex - -etex csplain.ini
>>  > >  pdfcsplain luatex - -etex csplain.ini
>>  > >  pdfcsplain pdftex - -etex -enc csplain-utf8.ini
>>  > >
>>  > > instead?
>>  >
>>  > This is probably not true. The tl2013 includes the
>>  > same text as tl2014 in fmtutil.cnf, i.e.:
>>  >
>>  > csplain pdftex - -etex -enc csplain-utf8.ini
>>  > pdfcsplain pdftex - -etex -enc csplain-utf8.ini
>>  > pdfcsplain xetex - -etex csplain.ini
>>  > pdfcsplain luatex - -etex csplain.ini
>>  >
>>  > and the symlinks are right (pdfcsplain -> pdftex) in tl2013.
>>
>> I just checked myself.  Symlinks are not created by fmtutil itself but
>> by Thomas Esser's texconfig.  When I change fmtutil.cnf as I suggested
>> and run "texconfig-sys init" I indeed get
>>
>
> I probably know the reason. I am doing my own build to verify it.
>
>>
>>   pdfcsplain -> pdftex
>>
>> However, texconfig is not an option because it's not running on
>> Windows and doesn't create wrappers for Windows.
>>
>> BTW, "tlmgr generate fmtutil" restores the original order.
>>
>> I must admit that I'm not very happy with three (format) files with
>> the same name in different directories.  Each engine finds the
>> appropriate format file but it's difficult to maintain symlinks, for
>> instance.
>>
>> In general I think that information like this should be in the config
>> file and the config file should be processed in a deterministic way.
>> However, since pdfcsplain is the only program which has this problem,
>> I'm convinced that it's not worth the trouble.  It should be
>> sufficient to restore the behavior of TL-2013.
>>
>> IMO it's a pity that fmtutil doesn't maintain the symlinks by itself.
>> There is no easy way to add such a feature without writing fmtutil
>> from scratch because we still have two different programs for Unix and
>> Windows.
>>
>> Regards,
>>   Reinhard
>>
>> --
>>
>> ----------------------------------------------------------------------------
>> Reinhard Kotucha                                      Phone:
>> +49-511-3373112
>> Marschnerstr. 25
>> D-30167 Hannover                              mailto:
>> reinhard.kotucha at web.de
>>
>> ----------------------------------------------------------------------------
>> Microsoft isn't the answer. Microsoft is the question, and the answer is
>> NO.
>>
>> ----------------------------------------------------------------------------
>>
>>
>
>
> --
> Zdeněk Wagner
> http://hroch486.icpf.cas.cz/wagner/
> http://icebearsoft.euweb.cz
>



-- 
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20140507/cd78c8ad/attachment.html>