Re: [gentoo-dev] /usr/share/texmf-site
On Fri, 28 Nov 2008, Ulrich Mueller wrote: We had similar code in app-emacs/auctex, but replaced it by hardcoded TEXMF="/usr/share/texmf-site" about one year ago. Tnanks, I'll do the same in maxima and asymptote. Andrey
Re: [gentoo-dev] /usr/share/texmf-site
> On Fri, 28 Nov 2008, Andrey Grozin wrote: > Some time ago, some Gentoo TeX guru (don't remember who) advised to > include the following code to the sci-mathematics/maxima ebuild: > [...code...] This code calls "kpsewhich" which means that the location of files installed by the ebuild will depend on the user's configuration. IMHO this is not a sane situation. (And the configuration may even change after installation of the package.) > So, probably, this code is an unneeded over-generalization, and > should be simply replaced by the hard-coded /usr/share/texmf-site in > both maxima and asymptote. We had similar code in app-emacs/auctex, but replaced it by hardcoded TEXMF="/usr/share/texmf-site" about one year ago. Ulrich
[gentoo-dev] /usr/share/texmf-site
Hello *,
Some time ago, some Gentoo TeX guru (don't remember who) advised to
include the following code to the sci-mathematics/maxima ebuild:
# Calculating MAXIMA_TEXMFDIR
if use latex; then
local TEXMFPATH="$(kpsewhich -var-value=TEXMFSITE)"
local TEXMFCONFIGFILE="$(kpsewhich texmf.cnf)"
if [ -z "${TEXMFPATH}" ]; then
eerror "You haven't defined the TEXMFSITE variable in your
TeX config."
eerror "Please do so in the file
${TEXMFCONFIGFILE:-/var/lib/texmf/web2c/texmf.cnf}"
die "Define TEXMFSITE in TeX configuration!"
else
# go through the colon separated list of directories
# (maybe only one) provided in the variable
# TEXMFPATH (generated from TEXMFSITE from TeX's config)
# and choose only the first entry.
# All entries are separated by colons, even when defined
# with semi-colons, kpsewhich changes
# the output to a generic format, so IFS has to be
redefined.
local IFS="${IFS}:"
for strippedpath in ${TEXMFPATH}; do
if [ -d ${strippedpath} ]; then
MAXIMA_TEXMFDIR="${strippedpath}"
break
fi
done
# verify if an existing path was chosen to prevent from
# installing into the wrong directory
if [ -z ${MAXIMA_TEXMFDIR} ]; then
eerror "TEXMFSITE does not contain any existing
directory."
eerror "Please define an existing directory in your
TeX config file"
eerror
"${TEXMFCONFIGFILE:-/var/lib/texmf/web2c/texmf.cnf} or create at least one of the
there specified directories"
die "TEXMFSITE variable did not contain an existing
directory"
fi
fi
fi
It is absolutely clear, and should work for arbitrarily configured TeX.
Later, I copied it (practically verbatim) to the media-gfx/asymptote
ebuild.
With the default Gentoo configuration of either teTeX or TeXlive, this
code always produces
/usr/share/texmf-site
There are a lot of packages which have this path hard-coded:
app-emacs/auctex
app-emacs/bbdb
app-text/passivetex
app-text/xetex
dev-tex/culmus-latex
dev-tex/currvita
dev-tex/dot2texi
dev-tex/envlab
dev-tex/europecv
dev-tex/feynmf
dev-tex/g-brief
dev-tex/glossaries
dev-tex/herm-pic
dev-tex/latex2html
dev-tex/latex-beamer
dev-tex/leaflet
dev-tex/listings
dev-tex/mh
dev-tex/oesch
dev-tex/pgf
dev-tex/svninfo
dev-tex/texmfind
dev-tex/translator
dev-tex/xcolor
dev-tex/xkeyval
dev-tex/xmltex
sci-visualization/gnuplot
So, probably, this code is an unneeded over-generalization, and should be
simply replaced by the hard-coded /usr/share/texmf-site in both maxima and
asymptote. Alternatively, if anybody thinks that this generalization can
be useful (in what case?), we could include this code as a function into
latex-package.eclass, and fix all the ebuilds listed above to use it. The
current inconsistent situation is not good.
I think the first solution is simpler (and I can do it myself). But if
somebody thinks this generalization to the case of an arbitrary TEXMFSITE
in TEXMFCONFIGFILE is useful, then let's do it properly.
Andrey
[gentoo-dev] RFC: DEFINED_PHASES magic metadata variable
I'd like to propose a new metadata variable called DEFINED_PHASES. Like
INHERITED, it will be generated by the package manager rather than by a
combination of explicit ebuild and eclass variables.
The DEFINED_PHASES variable is for package manager use; it may or may
not be exported to the ebuild, and must not be used or set in any way by
ebuilds. The DEFINED_PHASES proposal has (almost -- see below) no
developer-visible effects, other than reserving a variable name.
The name DEFINED_PHASES is currently only for convenience, since the
metadata cache format uses fixed positions rather than a key=value
format, but this may change in the future. In flat metadata cache,
DEFINED_PHASES shall be line 17.
The DEFINED_PHASES variable will contain a space separated arbitrarily
ordered list of phase names. A phase name is listed in DEFINED_PHASES if
and only if the ebuild or an eclass used by that ebuild provides an
implementation of that phase's phase function. For example, the current
value for app-editors/vim-7.2.021 would be (possibly not in this order):
DEFINED_PHASES="setup unpack compile install test postinst postrm"
If an ebuild uses the defaults for every single phase, rather than
defining a blank DEFINED_PHASES, the package manager shall set it to the
string "-". This will let the package manager tell the difference
between "this metadata was generated by an old package manager" and
"this ebuild uses defaults for everything".
Support for DEFINED_PHASES shall be optionally retroactively added to
all existing EAPIs. Package managers are not required to generate it,
and package managers may not assume its existence. Future EAPIs may make
DEFINED_PHASES mandatory.
Having DEFINED_PHASES upfront is useful in a number of ways to the
package manager:
* It lets the package manager avoid having to run phases that have a "do
nothing" default and that aren't defined by the ebuild. This is
currently a fairly minor issue, but in the future if we start using
src_fetch_extra (bug 249086) or pkg_pretend it makes quite a bit of
difference.
* It lets the package manager parallelise pkg_* functions in many
situations.
* It lets the package manager avoid having to go to 'interactive' mode
for every phase of PROPERTIES=interactive ebuilds.
There is one subtle implication of this proposal: it means the phases
defined by an ebuild must now be metadata-invariant. So the following is
remains legal:
if [[ ${EAPI} == 2 ]] ; then
src_configure() {
blah
}
fi
But this goes from being "probably illegal, but might work by fluke" to
"definitely illegal":
if use foo ; then
src_configure() {
blah
}
fi
This is of course a good thing.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
