[gentoo-dev] TeXLive modular ebuilds ready(?) for the main portage tree

[gentoo-dev] TeXLive modular ebuilds ready(?) for the main portage tree

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]

Dear list, 

As some of you may or may not know, I've been working on modular
texlive ebuilds[1], based on work found on b.g.o and pclouds work [2].
I wanted to send a mail earlier but time was lacking to fix the few
remaining bugs.

I've had several success reports, and fixed the remaining (known) bugs
there. I was thinking that it might be time to integrate this to the
official tree, as a first shoot under package.mask.

The layout I've been using is a modular one:
- texlive-core package that builds the required binaries. That's the
only one that should be system dependant.
- several texmf modules based on upstream "collection"s (that's how
they call them) that agregates packages from CTAN in some more or less
independant categories.

I've tried to remove as much as possible programs from the -core
package, as long as they had their independant ebuilds equivalent and
added the independant packages as dependencies of the texlive meta
ebuild.


As you might guess it, having a modular layout can give dependencies
problems. I was thinking about adding some (new style) virtuals to
handle them : 
- virtual/tex-base : programs that need only standard tex binaries or
libraires (like kpathsea) but do not need it to compile latex files for
example. There are a very very few of such packages and are ok with the
next virtual, so I dunno if that one is really necessary, apart for
reducing deps to the minimal set.
- virtual/latex-base : packages that need a (basic) latex, for example
to compile their documentation. This virtual will help preventing from
having circular dependencies between ebuilds (esp. the meta ebuild and
its dependencies)
- virtual/latex-full : a full latex distribution installation, what
other tex distributions like tetex provide. This one can use the current
old style virtual (virtual/tetex) instead of being a new one, but the
name is better imho.

So in the end, only latex-base is strictly required to merge this.
tex-base and latex-full have their improvements but can benefit from
discussion here.


Everything in [1] could still benefit of any kind of reviewing,
especially the eclasses. I'll also need to write a more decent guide on
how to use/switch to those ebuilds, so that it can be put on the
website.

The only (known) bug still left so far is that metapost (mpost) isn't
useable on hardened kernel, it gets killed. It is not a regression from
tetex, but apparently nobody ever noticed that. Now that ebuilds
generate the format files themselves in src_compile (this way we can
improve QA imho), instead of having texmf-update doing it in
pkg_postinst, some ebuilds will fail to install instead of silently not
creating the format file. (though texmf-update will still recreate the
formats so that they get updated with the texmf tree)

Something that annoys me is the license : there is [3], [4] and [5], so
GPL-2 might probably be fine, but I'm definitely not a lawyer...


In the (very hypothetic) case where nobody would have anything to add
there, I'll start merging this to the main tree, but definitely not
until the next week as I'll be away from wednesday to sunday.


And of course, many thanks to all the people who helped there: the
early testers when documentation was lacking but not bugs, the people
who suggested improvements (be it to ebuilds, the packaging layout or
documentation), bug fixes, reported bugs, or just mailed me about a
successful installation.

Now a question to arch teams : Should I keyword this for systems I've
tested it or just add without keywords and let you do another layer of
checks ? I've been using it on ~x86 (and hardenend but mpost had
problems), ~amd64 and ~ppc64 (this one has some missing deps, but don't
worry I'll poke you as soon as I'll have done extra checks ;) ).


As a side note, I'll have to send 1.3k+ files to distfiles-local as
upstream does not provide versionned names of the source files, for a
total of ~700-800M. Since this is huge, I hope infra has no particular
objection to it.

Alexis.


[1] http://overlays.gentoo.org/dev/aballier/
[2] http://dev.gentoo.org/~pclouds/texlive/overlay/
[3] http://www.tug.org/svn/texlive/trunk/Master/LICENSE.TL?view=markup
[4] http://www.tug.org/svn/texlive/trunk/Master/LICENSE.CTAN?view=markup
[5] http://www.tug.org/texlive/copying.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]

Alexis Ballier <aballier@gentoo.org>:
> I've had several success reports, and fixed the remaining (known) bugs
> there. I was thinking that it might be time to integrate this to the
> official tree, as a first shoot under package.mask.

 You would make so many people happy, if one has a look at the size of
the CC field on the bug. 

> As you might guess it, having a modular layout can give dependencies
> problems. I was thinking about adding some (new style) virtuals to
> handle them : 
> - virtual/tex-base : programs that need only standard tex binaries or
> libraires (like kpathsea) but do not need it to compile latex files
> for example. There are a very very few of such packages and are ok
> with the next virtual, so I dunno if that one is really necessary,
> apart for reducing deps to the minimal set.

 I am against it, as it will make maintenance a bit harder.

> - virtual/latex-base : packages that need a (basic) latex, for example
> to compile their documentation. This virtual will help preventing from
> having circular dependencies between ebuilds (esp. the meta ebuild and
> its dependencies)
> - virtual/latex-full : a full latex distribution installation, what
> other tex distributions like tetex provide. This one can use the
> current old style virtual (virtual/tetex) instead of being a new one,
> but the name is better imho.

 Full ack with those two.  It is a pain in the ass to maintain 1000s of
ebuilds in the tree for every single LaTeX package that TeXLive
provides so I am all in favour of a install all.
 
> Something that annoys me is the license : there is [3], [4] and [5],
> so GPL-2 might probably be fine, but I'm definitely not a lawyer...

 You can add several licenses to LICENSE.  And a lot of packages are
LPPL, so you really need to adjust it.  There has been a discussion on
the TeXLive about the licenses [1].

> Now a question to arch teams : Should I keyword this for systems I've
> tested it or just add without keywords and let you do another layer of
> checks ? I've been using it on ~x86 (and hardenend but mpost had
> problems), ~amd64 and ~ppc64 (this one has some missing deps, but
> don't worry I'll poke you as soon as I'll have done extra checks ;) ).

 I am all for new keywording as it is a major step forward from teTeX.
 
> As a side note, I'll have to send 1.3k+ files to distfiles-local as
> upstream does not provide versionned names of the source files, for a
> total of ~700-800M. Since this is huge, I hope infra has no particular
> objection to it.

 Talk to them directly.

V-Li

[1] <URL:http://thread.gmane.org/gmane.comp.tex.live/14569>

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]


> > Something that annoys me is the license : there is [3], [4] and [5],
> > so GPL-2 might probably be fine, but I'm definitely not a lawyer...
> 
>  You can add several licenses to LICENSE.  And a lot of packages are
> LPPL, so you really need to adjust it.  There has been a discussion on
> the TeXLive about the licenses [1].

thanks for the link, switched to LPPL1.3c & GPL-2 as base licenses plus
some extra ones based on fedora's reviews on a per package basis.

> > Now a question to arch teams : Should I keyword this for systems
> > I've tested it or just add without keywords and let you do another
> > layer of checks ? I've been using it on ~x86 (and hardenend but
> > mpost had problems), ~amd64 and ~ppc64 (this one has some missing
> > deps, but don't worry I'll poke you as soon as I'll have done extra
> > checks ;) ).
> 
>  I am all for new keywording as it is a major step forward from teTeX.


will do like that



Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree

[Ulrich Mueller]

>>>>> On Sun, 30 Sep 2007, Alexis Ballier wrote:

> As you might guess it, having a modular layout can give dependencies
> problems. I was thinking about adding some (new style) virtuals to
> handle them :

> - virtual/tex-base : programs that need only standard tex binaries
> or libraires (like kpathsea) but do not need it to compile latex
> files for example. There are a very very few of such packages and
> are ok with the next virtual, so I dunno if that one is really
> necessary, apart for reducing deps to the minimal set.

> - virtual/latex-base : packages that need a (basic) latex, for
> example to compile their documentation. This virtual will help
> preventing from having circular dependencies between ebuilds (esp.
> the meta ebuild and its dependencies)

> - virtual/latex-full : a full latex distribution installation, what
> other tex distributions like tetex provide. This one can use the
> current old style virtual (virtual/tetex) instead of being a new
> one, but the name is better imho.

> So in the end, only latex-base is strictly required to merge this.
> tex-base and latex-full have their improvements but can benefit from
> discussion here.

I would be strongly in favour of adding also the tex-base virtual [1].

Packages requiring plain TeX are now migrated to IUSE=tex, as
suggested in bug #196745 [2], and it is not consistent if they must
now depend on virtual/latex-base.

Of course one could add explicit any-of-many dependencies for
texlive-core or {te,p,cste}tex everywhere, but I think it is much
better if this is handled in one place.

Ulrich

[1] <http://overlays.gentoo.org/dev/aballier/browser/texlive-overlay/virtual/tex-base>
[2] <https://bugs.gentoo.org/196745#c4>
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

Ulrich Mueller <ulm@gentoo.org>:

> I would be strongly in favour of adding also the tex-base virtual [1].

 When I spoke against it, I assumed there would be near to no packages
which could use it...so I change my opinion.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

Hi,


> I would be strongly in favour of adding also the tex-base virtual [1].

+1

> Packages requiring plain TeX are now migrated to IUSE=tex, as
> suggested in bug #196745 [2], and it is not consistent if they must
> now depend on virtual/latex-base.
> 
> Of course one could add explicit any-of-many dependencies for
> texlive-core or {te,p,cste}tex everywhere, but I think it is much
> better if this is handled in one place.


I've fixed a typo for cstetex (cstex doesnt exist, oops ^^). Anyway, I
doubt anybody will try to resurect it and it'll be gone in a few weeks.

Note that plain.tex is provided by texlive-basic, so stricto senso it
doesn't provide support for "Plain TeX", only TeX. It also provides
kpathsea, so packages using only kpathsea might benefit from it also.

If nobody is against it, feel free to commit this (with or without
cstetex, as you wish, I'll kill references to it before removing it
anyway); or I'll do it when I'll have some time, most likely this week
end.

Regards,

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree

[Ulrich Mueller]

>>>>> On Thu, 22 Nov 2007, Alexis Ballier wrote:

>> I would be strongly in favour of adding also the tex-base virtual.

> +1

> [...]

> If nobody is against it, feel free to commit this (with or without
> cstetex, as you wish, I'll kill references to it before removing it
> anyway); or I'll do it when I'll have some time, most likely this
> week end.

virtual/tex-base committed, since there were no voices against it.

Ulrich
-- 
gentoo-dev@gentoo.org mailing list