This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport suggestion: src_postinstall
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin-apps <cygwin-apps at cygwin dot com>
- Date: Sun, 11 Mar 2012 08:52:57 -0400
- Subject: Re: cygport suggestion: src_postinstall
- References: <4F5A7582.email@example.com> <4F5A8B16.firstname.lastname@example.org> <4F5A97FB.email@example.com> <4F5C3DD8.firstname.lastname@example.org>
[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
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.
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)
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
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.
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.