Ludovic Courtès <l...@gnu.org> writes:

> Ricardo Wurmus <rek...@elephly.net> skribis:
>
>> Ludovic Courtès <l...@gnu.org> writes:
>>
>>> Ricardo Wurmus <rek...@elephly.net> skribis:
>>>
>>>> * gnu/packages/tex.scm (texlive-texmf-minimal)[arguments]: Move contents
>>>> of "prune" build phase...
>>>> [source]: ...to a snippet here.
>>>
>>> It looks nicer this way, but a possible downside is the extra derivation
>>> and recompression of the patched source.
>>>
>>> No strong opinion here though.
>>
>> My motivation was probably misguided.  My hope was that building
>> “texlive-texmf-minimal” would no longer require the very large download
>> of the full texlive-texmf sources but only the much smaller pruned
>> sources.  If this is the case I think it would be advantageous for
>> users.  However, if building from source would cause them to download
>> the big tarball first, then patch and repack, and then build the package
>> — that would obviously not be great.
>>
>> Do we provide substitutes for snippet-patched sources?
>
> Yes, as long as there’s a derivation, there’s a substitute.
>
> But really, we should get rid of this monolithic texlive and import
> individual CTAN packages, while still providing a big texlive
> meta-package for those who want the 4GiBs.

Yes, I agree.

I made the change when I was still hoping to be able to build the Python
science suite (numpy, scipy, matplotlib…) with texlive-minimal, which
turned out to fail in all instances.  It always missing a different tiny
subset of Texlive…

Texlive is one of the biggest annoyances here at the MDC.  The huge
package together with slow storage (and our users’ dependence on things
like numpy) means that I’m rebuilding Texlive for half a day each time I
update our shared Guix installation.  I’m *very* motivated to change
this.

I’ll build a CTAN (bulk) importer soon and will see where that leads us.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net


Reply via email to