From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: bug#27217: texlive is too big Date: Thu, 10 Jan 2019 17:01:48 +0100 Message-ID: <87ftu04i37.fsf@ambrevar.xyz> References: <87tw3w7v1m.fsf@elephly.net> <87po1g2g43.fsf@gmail.com> <87fu2chu02.fsf@elephly.net> <87lgc42b7i.fsf@gmail.com> <87va2wdfq8.fsf@gnu.org> <87pnt44zc7.fsf@ambrevar.xyz> <87wonc4rvg.fsf@elephly.net> <87o98o4qwn.fsf@ambrevar.xyz> <87muo84jcu.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:35381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghcmW-0003na-An for bug-guix@gnu.org; Thu, 10 Jan 2019 11:02:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ghcmP-0000jW-T6 for bug-guix@gnu.org; Thu, 10 Jan 2019 11:02:08 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:54826) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ghcmP-0000jR-PU for bug-guix@gnu.org; Thu, 10 Jan 2019 11:02:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ghcmP-0006wc-M2 for bug-guix@gnu.org; Thu, 10 Jan 2019 11:02:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87muo84jcu.fsf@elephly.net> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ricardo Wurmus Cc: 27217@debbugs.gnu.org > What I find most troubling is that sources are littered across the SVN > repository. Sometimes we=E2=80=99ve 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 cleare= r: there is simply no general recipe for building TeXlive packages. TeXlive packages are provided "ready to use", they are not meant to be buil= t. The .ins/.dtx are only here for potential package contributors or as a sour= ce 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 th= em have confusing licenses, and since the source is missing, I wouldn't call t= hat "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=E2=80=99t 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.tlpd= b.xz. > So, it=E2=80=99s a map of packages to file names? That would probably si= mplify > the importer. I don=E2=80=99t think it would help with the build system.= Am I > missing something? I believe the tlpdb might actually be necessary to build every package reli= ably. 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 an= d 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 .sty file beside the one exis= ting 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 g= et the synopsys/license information from the tlpdb. Does that make sense?