Re: [gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree
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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree
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.
signature.asc
Description: PGP signature
[gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree
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
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree
Ulrich Mueller [EMAIL PROTECTED]: 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/ signature.asc Description: PGP signature
[gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage tree
Alexis Ballier [EMAIL PROTECTED]: 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/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: TeXLive modular ebuilds ready(?) for the main portage 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... 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. signature.asc Description: PGP signature
