TexLive 2009 plans Re: [MacPorts] #16492: UPDATE: TexLive 2007 to newer version

[Jeremy Lavergne]

Your proposal sounds reasonable to me; that is a very similar approach to what Ubuntu (debian) takes, and I think it works fine.

I really wish texlive would do what miktex does and use a package manager for each individual package. but oh well. Their collections make pretty good sense as divisions.

On Feb 17, 2010, at 6:03 PM, Dan Ports wrote:

> I posted the following comments about the work I'm doing on updating
> the texlive ports to v2009 in a ticket, but since they are some
> fairly large changes, I thought I'd send them to -dev too. (Apologies
> for the spam to anyone who already received it.)
> 
> Any comments are appreciated.
> 
> Dan
> 
> On Wed, Feb 17, 2010 at 10:49:25PM -0000, MacPorts wrote:
>> #16492: UPDATE: TexLive 2007 to newer version
>> ---------------------------------+------------------------------------------
>> Reporter:  luis.beca@???          |       Owner:  milosh@???           
>>     Type:  update               |      Status:  new                
>> Priority:  Normal               |   Milestone:                     
>> Component:  ports                |     Version:                     
>> Keywords:                       |        Port:  texlive            
>> ---------------------------------+------------------------------------------
>> 
>> Comment(by dports@???):
>> 
>> Let me say a few words about what I'm working on with the texlive port so
>> that people know what's going on -- looks like there's been a lot of
>> interest in a more recent TeXLive lately.
>> 
>> For background, texlive is a large and lumbering monstrosity. It includes
>> a giant pile of source code (complete with all of its dependent
>> libraries), an even more giant pile of TeX packages, and its own package
>> manager. I believe texlive 2009 is divided into over 3000 packages, which
>> are grouped into about 80 "collections", and further grouped into 10
>> "schemes".
>> 
>> The version currently in MacPorts is 2007, which IIRC predates TexLive's
>> package management system. So there's a texlive_base port that installs
>> the binaries, a texlive_texmf-full and a texlive_texmf-minimal that
>> install some or all of the tex files, s texlive_texmf-docs port, and a
>> texlive metaport.
>> 
>> This organization doesn't really work for TL 2009, because there's no
>> "minimal" texmf tree anymore and it's not really clear exactly what we'd
>> want to put in a "minimal" install anyway. And I would really rather not
>> support only a full install of texlive, because that's about a gig of
>> distfiles and probably over 2GB installed. Instead, I'd like to provide
>> finer granularity so that users can choose what they want installed.
>> 
>> So my plan is to create the following ports:
>>  * texlive-common, which contains support scripts and files required for
>> building and installing the others (e.g. texmf.cnf)
>>  * texlive-bin, which contains everything built from source (not too
>> different from today's texlive_base)
>>  * one port per texlive collection, e.g. texlive-basic, texlive-latex-
>> recommended, texlive-lang-african
>> 
>> I'm leaning toward one port per collection because I think this is the
>> only option with a decent granularity and a reasonable number of ports. It
>> would wind up creating 80-90 ports, which is a lot, but not totally
>> unreasonable to me. (Note that 30 of these are language-specific packages
>> for 30 languages, and another 24 are documentation in different
>> languages.) This is basically the approach that Debian takes.
>> 
>> The other alternatives are one port per package, which would be great in
>> that you could install exactly the packages you need, but require 3000+
>> ports, which would be a nightmare. One port per scheme (there are 10 of
>> them) would also be a decent option, except that the schemes overlap, so
>> the ports would conflict. I think one port per collection is the way to
>> go.
>> 
>> I've done a lot of the work necessary for this, including getting the
>> binaries to build and the giant distfile carved up into more manageable
>> collections. I can provide more details if anyone is interested, and I
>> hope to have a patch soon once I get it into reasonably usable shape.
>> 
>> This has been even more of a painful mess than I expected it to be!
>> 
>> -- 
>> Ticket URL: <http://trac.macports.org/ticket/16492#comment:47>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS
>> 
> 
> -- 
> Dan R. K. Ports              MIT CSAIL                http://drkp.net/
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20100217/bcb1034d/attachment-0001.bin>