cygport suggestion: src_postinstall
Ken Brown
kbrown@cornell.edu
Sun Mar 11 14:46:00 GMT 2012
On 3/11/2012 8:52 AM, Ken Brown wrote:
> [moving from cygwin to cygwin-apps]
>
> On 3/11/2012 12:53 AM, Yaakov (Cygwin/X) wrote:
>> On 2012-03-09 17:53, Ken Brown wrote:
>>> On 3/9/2012 5:58 PM, Yaakov (Cygwin/X) wrote:
>>>> On 2012-03-09 15:26, Ken Brown wrote:
>>>>> and I don't like some of the things that are done in __src_postinst
>>>>> when
>>>>> I build that package.
>>>>
>>>> Could you specify?
>>>
>>> There are two things:
>>>
>>> 1. I don't think __prepemacs should be called for this package because
>>> the compile process explicitly byte compiles most of the *.el files.
>>> There are three (at the top level of /usr/share/emacs/site-lisp) that it
>>> does not byte compile. I don't know the reason, but I don't think the
>>> Cygwin build should override this upstream decision.
>>
>> The official way to avoid byte compilation is with no-byte-compile[1].
>> preview-latex.el and tex-site.el are so marked, so they won't be
>> compiled anyway. auctex.el is not so marked, so either there is no
>> reason to not compile it, or else it should also be marked; either way,
>> this should be fixed upstream.
>
> OK. But if you look at the command that does the byte-compiling in the
> auctex sources, it includes `-l lpath.el'. The contents of lpath.el are:
>
> ;;; This file is only used for installing AUCTeX.
> ;;; It is not a part of AUCTeX itself.
>
> ;; Make sure we get the right files.
> (setq load-path (cons "." load-path)
> byte-compile-warnings nil
> TeX-lisp-directory "<none>"
> TeX-auto-global "<none>")
>
> By re-byte-compiling without this, we run the risk of messing something
> up. So I still think it's wrong to call __prepemacs on this package. If
> you don't like my suggestion of providing src_postinstall, then I think
> there should be a different way for cygport users to have some control
> over the postinstall process. What about defining variables (like
> PREPEMACS, etc.) that allow the user to turn the __prep* functions on or
> off?
>
>>> 2. I would prefer that __prep_texlive not be called, since it causes the
>>> postinstall script to do unnecessary work. All that's needed for auctex
>>> is mktexlsr.
>>
>> Then we should figure out how to fine-tune __prep_texlive(). The first
>> mktexlsr is always needed, and the updmap-sys will be limited to
>> packages including Add*Map command(s) per our other thread. Should we
>> limit the fmtutil-sys call to packages including addFormat command(s)?
>
> That seems like a good idea. But what about packages that include
> addHyphen commands? I'm not sure whether formats have to be rebuilt
> after such packages are installed. In any case, there's probably
> something that needs to be done for such packages.
I've just looked at tlmgr.pl, and it does appear that fmtutil needs to
be called if there's an AddHyphen command. But first the relevant
languages are regenerated. This involves calls to create_language_dat,
create_language_def, and create_language_lua. All of this seems pretty
complicated and hard to get right if we try to do it ourselves.
Maybe it would be better for the postinstall scripts to make use of the
capabilities of /usr/share/texmf/scripts/texlive/tlmgr.pl. For example,
it accepts the commands
generate language
generate language.dat
generate language.def
generate language.dat.lua
generate fmtutil
generate updmap
Or do you have a better idea? Do you know what the Linux distros do? I
imagine you looked at one or more of these before packaging TeX Live.
>> Do any non-texlive packages add anything which would necessitate a call
>> to updmap-sys and/or fmtutil-sys?
>
> I don't think so. The only non-texlive package in the distro that adds
> anything to /usr/share/texmf is gnuplot, and it only adds a .sty file
> and a .cfg file.
>
> Ken
More information about the Cygwin-apps
mailing list