Bug 229217 - app-text/xindy keyword request (will be needed for texlive 2008)
|
Bug#:
229217
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: tex@gentoo.org
|
Reported By: aballier@gentoo.org
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: app-text/xindy keyword request (will be needed for texlive 2008)
|
|
Keywords: KEYWORDREQ
|
|
Status Whiteboard:
|
|
Opened: 2008-06-24 15:00 0000
|
Hi all,
I've started to work on TeX Live 2008. This release will include xindy but I
won't use the one bundled with it since we have an ebuild for xindy. I'll just
make the meta ebuild (app-text/texlive) to depend on it (probably with xindy
useflag).
Please give it a try and if it works, ~arch it. Thanks.
If it is really not possible to make it work on your arch, we'll have to
arrange an use mask entry for texlive 2008.
xindy has
RDEPEND=" ... >=dev-lisp/clisp-2.44.1-r1 ..."
This is a problem for sparc: clisp is '-sparc' because it will not build at
all on sparc. For us to proceed, xindy needs an alternate version of lisp
(sbcl is good on sparc, for example).
I'll leave sparc in CC list so that you can respond.
(In reply to comment #1)
> xindy has
> RDEPEND=" ... >=dev-lisp/clisp-2.44.1-r1 ..."
> This is a problem for sparc: clisp is '-sparc' because it will not build at
> all on sparc. For us to proceed, xindy needs an alternate version of lisp
> (sbcl is good on sparc, for example).
The problem is xindy really needs clisp (or that I don't know how to make it
use sbcl) :( It builds a clisp module if I remember correctly; the common-lisp
people are probably much wiser than me on that side.
wrt the >= dep, that's because there was a "bug" in previous clisp ebuilds that
allowed portage to strip objects needed to build a module and then the objects
became unusable (for some reason some symbols got removed while they are needed
when building a module against it).
I was expecting such problems, that's why I suggested it will be possible to
use.mask it.
clisp fails on alpha and ia64, and probably on hppa too(didn't try). However
debian uses some flags to skip those failures(related with mmap stuff).
And on sparc...debian doesn't have it keyworded, i don't remember exactly what
i did, but i got it complaining about some c file missing. Will have a look
when i have it fixed for the first two arches.
dev-lisp/clisp won't build on HPPA either.
For sparc, this is a problem. It looks like dev-lisp/clisp is required for
xindy. However, on sparc clisp is marked '-sparc' because last I knew, it
would not build at all. Perhaps someone else has better information about
clisp, but last time I tried to build it, the failures were fundamental
(assembly code related, I think).
The app-text/texlive:xindy USE flag is now package.use.masked for HPPA.
(In reply to comment #6)
> For sparc, this is a problem. It looks like dev-lisp/clisp is required for
> xindy. However, on sparc clisp is marked '-sparc' because last I knew, it
> would not build at all. Perhaps someone else has better information about
> clisp, but last time I tried to build it, the failures were fundamental
> (assembly code related, I think).
>
clisp won't build because of a sparc/sparc64 confusion in arch detection. If
you force it to build, it will not run at all. So xindy is really not an
option for sparc unless it can use some other lisp interpreter instead.
maybe we could close this one as fixed now that it's masked where chances are
low that it can run ?
(In reply to comment #9)
> maybe we could close this one as fixed now that it's masked where chances are
> low that it can run ?
>
From sparc's point of view, it can be closed. Chances are 0 that it will run
unless either (1) upstream fixes clisp for sparc/linux, or (2) xindy learns how
to use a different lisp interpreter, like sbcl.
closing then
ppc is done
clisp doesn't build on ppc64 afaik
bsd has issues with bsdmake + the way clisp builds its modules, i'll try to get
that fixed someday...