unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: texlive-texmf-minimal: Prune in snippet.
Date: Thu, 01 Dec 2016 16:04:33 +0100	[thread overview]
Message-ID: <87wpfjd726.fsf@elephly.net> (raw)
In-Reply-To: <87shq7sqaz.fsf@gnu.org>


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

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Ricardo Wurmus <rekado@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	other threads:[~2016-12-01 15:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29 11:32 [PATCH] gnu: texlive-texmf-minimal: Prune in snippet Ricardo Wurmus
2016-11-29 15:00 ` Ludovic Courtès
2016-11-29 22:41   ` Ricardo Wurmus
2016-12-01 13:59     ` Ludovic Courtès
2016-12-01 15:04       ` Ricardo Wurmus [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wpfjd726.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).