all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pierre Neidhardt <mail@ambrevar.xyz>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: 27217@debbugs.gnu.org
Subject: bug#27217: texlive is too big
Date: Thu, 10 Jan 2019 17:01:48 +0100	[thread overview]
Message-ID: <87ftu04i37.fsf@ambrevar.xyz> (raw)
In-Reply-To: <87muo84jcu.fsf@elephly.net>


> What I find most troubling is that sources are littered across the SVN
> repository.  Sometimes we’ve got simple .ins and .dtx files, but very
> often we have a stray .sty or .tex file in some seemingly arbitary
> directory and one needs to manually take care of adding these extra
> source files to the native-inputs.

I was puzzled like you, but last time I investigated it became a bit clearer:
there is simply no general recipe for building TeXlive packages.

TeXlive packages are provided "ready to use", they are not meant to be built.
The .ins/.dtx are only here for potential package contributors or as a source of
documentation, but when it comes to TeXlive, they are not used to build the
resulting package.  The .sty is (I think) always parachuted into the SVN
repository as well.

(Actually, sometimes there is no .ins/.dtx, just a .sty.)

More worrisome: some fonts don't provide their source.  In fact, some of them
have confusing licenses, and since the source is missing, I wouldn't call that
"free software".  But TeXlive is.  That's not very consistent and a lot of FOSS
TeXlive packages effectively depend on closed-source fonts.

What shall do then?

> I don’t see this file in the texlive SVN repository.  Where is it
> hosted?

It's in Master/tlpkg/texlive.tlpdb.
Or from CTAN:
http://mirror.ctan.org/tex-archive/systems/texlive/tlnet/tlpkg/texlive.tlpdb.xz.

> So, it’s a map of packages to file names?  That would probably simplify
> the importer.  I don’t think it would help with the build system.  Am I
> missing something?

I believe the tlpdb might actually be necessary to build every package reliably.

As I said above, TeXlive packages are not meant to be built, they are meant to
be copy/pasted, so it seems.  (Correct me if I'm wrong.)

Sure we can rebuild the .dtx/.ins, but that only works for some packages and it
does not suffice, we still need to include the extra files (e.g. fonts) if any.
We can only know this file list from the tlpdb.

So here is what I suggest: the texlive-build-system looks up the file list in
the tlpdb and copies everything.  If some of those files include .dtx/.ins,
it could build them (but that should not change anything since the .sty is
always provided).

Question: that would produce another <package>.sty file beside the one existing
in the SVN.  Should we replace it?  Should we print a warning if it does not
match?

With such a build system, the only thing the importer would have to do is get
the synopsys/license information from the tlpdb.

Does that make sense?

  reply	other threads:[~2019-01-10 16:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03 19:03 bug#27217: texlive is too big Ricardo Wurmus
2017-11-23 20:51 ` bug#27217: break up TeXlive for guix Matt Wette
2018-01-23 13:20 ` bug#27217: texlive is too big Mathieu Lirzin
2018-05-28 12:02   ` Ricardo Wurmus
2018-05-28 11:07 ` Peter Neidhardt
2018-05-28 11:58   ` Ricardo Wurmus
2018-05-28 12:53     ` Peter Neidhardt
2018-12-15 14:11       ` Pierre Neidhardt
2019-01-10  9:27       ` Ludovic Courtès
2019-01-10  9:49         ` Pierre Neidhardt
2019-01-10 12:30           ` Ricardo Wurmus
2019-01-10 12:51             ` Pierre Neidhardt
2019-01-10 15:34               ` Ricardo Wurmus
2019-01-10 16:01                 ` Pierre Neidhardt [this message]
2019-01-10 16:11                   ` Ricardo Wurmus
2019-01-10 17:47                     ` Pierre Neidhardt
2019-01-10 18:50                       ` Ricardo Wurmus
2019-01-10 18:56                         ` Pierre Neidhardt
2019-01-10 19:01                           ` Ricardo Wurmus
2019-01-10 11:27         ` Ricardo Wurmus
2019-01-10 12:15           ` Ludovic Courtès
2019-01-13 12:21             ` Ricardo Wurmus
2019-01-17  9:36               ` Ludovic Courtès
2019-01-17  9:41                 ` Pierre Neidhardt
2019-01-17 10:39                   ` Ricardo Wurmus
2019-01-17 10:43                     ` Pierre Neidhardt
2019-01-17 11:01                       ` Ricardo Wurmus
2019-03-02 14:13                         ` Pierre Neidhardt
2019-03-03 14:32                           ` Jelle Licht
2019-03-05  8:39                             ` Pierre Neidhardt
2019-03-16 12:59                               ` Pierre Neidhardt
2019-03-18  8:47                                 ` Ludovic Courtès
2019-03-19 21:36                                   ` Ricardo Wurmus
2019-03-20  7:47                                     ` Pierre Neidhardt
2019-03-22 21:01                                       ` Ludovic Courtès
2019-01-17 10:36                 ` Ricardo Wurmus
2019-01-15 15:34 ` Ricardo Wurmus

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

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

  git send-email \
    --in-reply-to=87ftu04i37.fsf@ambrevar.xyz \
    --to=mail@ambrevar.xyz \
    --cc=27217@debbugs.gnu.org \
    --cc=rekado@elephly.net \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.