From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#27217: texlive is too big Date: Mon, 18 Mar 2019 09:47:15 +0100 Message-ID: <87imwgsh64.fsf@gnu.org> References: <87tw3w7v1m.fsf@elephly.net> <87po1g2g43.fsf@gmail.com> <87fu2chu02.fsf@elephly.net> <87lgc42b7i.fsf@gmail.com> <87va2wdfq8.fsf@gnu.org> <87zhs84urk.fsf@elephly.net> <87h8egd7zd.fsf@gnu.org> <878szooiix.fsf@elephly.net> <87a7jzy6ae.fsf@gnu.org> <87sgxr62p1.fsf@ambrevar.xyz> <87munzh8kj.fsf@elephly.net> <87imynsgxg.fsf@ambrevar.xyz> <87k1j3h7k4.fsf@elephly.net> <87imx1e541.fsf@ambrevar.xyz> <86bm2skozm.fsf@fsfe.org> <87a7i9ww82.fsf@atlas.engineer> <87y35ft1p7.fsf@ambrevar.xyz> 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]:34080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5nwF-0003gA-Ir for bug-guix@gnu.org; Mon, 18 Mar 2019 04:48:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5nwD-0000Jg-Il for bug-guix@gnu.org; Mon, 18 Mar 2019 04:48:07 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:34499) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h5nw9-0000ID-UU for bug-guix@gnu.org; Mon, 18 Mar 2019 04:48:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h5nw9-0004O6-Pd for bug-guix@gnu.org; Mon, 18 Mar 2019 04:48:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87y35ft1p7.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sat, 16 Mar 2019 13:59:16 +0100") 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: Pierre Neidhardt Cc: Jelle Licht , 27217@debbugs.gnu.org Hello! Pierre Neidhardt skribis: > Yesterday Jelle and I started getting down to it. > > I've created a wip-texlive branch. For now, we can run > > (texlive-fetch "xcolor")=20 > > and it returns the appropriate parsed entry from the tlpdb from texlive-b= in. Nice! > The first call to texlive-fetch takes some 10-30 seconds because the tlpd= b is > some 11MB+ big. > > I'm caching the parsed DB, so that should not be a problem during develop= ment. You can use =E2=80=98http-fetch/cached=E2=80=99, if that=E2=80=99s not what= you=E2=80=99re already doing. > I'm suggesting those following steps: > > - Write the package definition generator. We can take inspiration from > opam.scm, it seems to be well written and very similar. > `texlive-fetch' is already aligned with `opam-fetch'. >=20=20=20 > For testing, we can try to recreate a simple package definition. > texlive-latex-xcolor for instance. > There is an immediate difference already: the name generated by the imp= orter > will be texlive-xcolor and not texlive-latex-xcolor. > > - Write texlive-fetch so that we can write definitions with multiple > directories. >=20=20=20 > - Update the texlive-build-system to accommodate the importer. For insta= nce, we > will probably have to build fonts automatically. We will also have to = be > smart about the files that need to be generated, and those that need to= be discarded. > > - Write an updater (again, following opam.scm, should be trivial). > > I'll get started with the first step today. Let me know what you think! So TeX Live packages would use =E2=80=98texlive-fetch=E2=80=99 instead of = =E2=80=98svn-fetch=E2=80=99 or similar, right? If that=E2=80=99s the case, then merely computing the derivation of one of = these would require fetching the tldb database, which would be problematic. Is this correct? Thank you, Ludo=E2=80=99.