bug#27217: texlive is too big

Pierre Neidhardt skribis: > Ricardo Wurmus writes: > >>> So TeX Live packages would use ‘texlive-fetch’ instead of ‘svn-fetch’ or >>> similar, right? >>> >>> If that’s the case, then merely computing the derivation of one of these >>> would require fetching the tldb database, which would be

bug#27217: texlive is too big

Ludovic Courtès writes: >> 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'. >> >> For testing, we can try

bug#27217: texlive is too big

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") > > and it returns the appropriate parsed entry from the tlpdb from texlive-bin. Nice! > The first call to

bug#27217: texlive is too big

Fantastic! I have time to work on it this week, so let me know if you'd like some help :) Can't wait to get this sorted once and for all :D -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

bug#27217: texlive is too big

Pierre Neidhardt writes: > For posterity, here is a python importer for tlpdb: > > https://github.com/amaxwell/tlutility/blob/master/parse_tlpdb.py > > (Thanks to Henkjan for sharing this.) > > Jelle, did you work on the importer any further after FOSDEM? > Can you share the file, I'm afraid I

bug#27217: texlive is too big

Pierre Neidhardt writes: > What I meant is that with the tlpdb approach, we would base our build system > on > a centralized authority with regard to what constitute a package and which > files > belong to them. Then we would not have to worry about file conflicts. Ah, I see. I was

bug#27217: texlive is too big

Ludovic Courtès writes: > Hello! > > Ricardo Wurmus skribis: > >> Ludovic Courtès writes: >> >>> Now I can’t find the ‘pplr’ font (actually Adobe’s Palatino). >> >> In the texmf-dist tree these fonts are found under >> “fonts/{tfm,afm,vf/adobe/palatino”. I don’t know if there are any >>

bug#27217: texlive is too big

Pierre Neidhardt writes: > And this highlights another big issue with our current build system: it's very > hard to know which file is already packaged. It could very well be that some > texlive packages have conflicts simply because we've accidentally packaged the > same files in different

bug#27217: texlive is too big

As far as I know, we don't, and I could not figure the package out (I could have tried harder...). And this highlights another big issue with our current build system: it's very hard to know which file is already packaged. It could very well be that some texlive packages have conflicts simply

bug#27217: texlive is too big

Hello! Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Now I can’t find the ‘pplr’ font (actually Adobe’s Palatino). > > In the texmf-dist tree these fonts are found under > “fonts/{tfm,afm,vf/adobe/palatino”. I don’t know if there are any > sources for generating these files, or if

bug#27217: texlive is too big

Ricardo Wurmus writes: > We may also want to > support installation of individual packages by providing a profile hook > (e.g. when a user only wants texlive-minimal with the gbrief package). A profile hook has been added with commit 743497b5650713e082f4775a3b7dfd03babc8191. Users may want

bug#27217: texlive is too big

Ludovic Courtès writes: > Now I can’t find the ‘pplr’ font (actually Adobe’s Palatino). In the texmf-dist tree these fonts are found under “fonts/{tfm,afm,vf/adobe/palatino”. I don’t know if there are any sources for generating these files, or if they are simply font blobs. In the latter

bug#27217: texlive is too big

Pierre Neidhardt writes: >> I don’t think that’s correct. The .ins/.dtx files contain instructions >> for generating files, including the .sty files, which are extracted from >> the .dtx files. > > What I meant is that the .sty is always already generated in the SVN repo. Yes, the SVN repo

bug#27217: texlive is too big

Pierre Neidhardt writes: >> Yes, the SVN repo does include generated files. That’s not great, but >> we can choose to ignore those files (as we do in other projects). > > And the builder should take care not to discard .sty / .cls files that are not > going to be generated. I believe that in

bug#27217: texlive is too big

> Yes, the SVN repo does include generated files. That’s not great, but > we can choose to ignore those files (as we do in other projects). And the builder should take care not to discard .sty / .cls files that are not going to be generated. I believe that in all cases the basename remains

bug#27217: texlive is too big

> I don’t think that’s correct. The .ins/.dtx files contain instructions > for generating files, including the .sty files, which are extracted from > the .dtx files. What I meant is that the .sty is always already generated in the SVN repo. Can you find a counter-example? > We have both kinds

bug#27217: texlive is too big

Pierre Neidhardt writes: > 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

bug#27217: texlive is too big

> 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

bug#27217: texlive is too big

Hey Pierre, > I'm so sorry for the poor wording, Ricardo, it was uncalled for. (Wrote in a > haste.) What I meant is that it does not solve the current issue of "what > file > belongs to what package." No worries :) > It's not just the importer but our current approach to TeXlive that

bug#27217: texlive is too big

Hi Pierre, > I think I know what's happening: some packages are missing files because they > were not properly packaged. With our current build system, this is almost > impossible to fix. > > I've never been able to use the importer. Anyways, as my previous email > pointed out, I think it's

bug#27217: texlive is too big

Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Hello! >> >> I was also looking at the remaining dependencies on ‘texlive’. For >> ‘teximpatient’, it looks like we’d need >> but: [...] >> Throw to key `srfi-34' with args `(#> arguments: ("checkout"

bug#27217: texlive is too big

Ludovic Courtès writes: > Hello! > > I was also looking at the remaining dependencies on ‘texlive’. For > ‘teximpatient’, it looks like we’d need > but: > > --8<---cut here---start->8--- > $ guix import texlive mflogo-font

bug#27217: texlive is too big

Hello! I was also looking at the remaining dependencies on ‘texlive’. For ‘teximpatient’, it looks like we’d need but: --8<---cut here---start->8--- $ guix import texlive mflogo-font ni sekvas la redirektigon al

bug#27217: texlive is too big

I've dug into this a little deeper (sadly not too much, I don't think I'll have time to work on this before a while). Let me summarize the issue: packages can be fetched from two main resources: - the TeXlive subversion repository (what we are doing now) which bundles everything into a single

bug#27217: texlive is too big

Also it seems that the texlive importer is broken: --8<---cut here---start->8--- > guix import texlive fontspec following redirection to `https://ctan.org/xml/1.2/pkg/fontspec'... Backtrace: 10 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 9

bug#27217: texlive is too big

Mathieu Lirzin writes: > Ricardo Wurmus writes: > >> What’s missing? >> >> Currently, one needs to set a lot of environment variables to use these >> separate packages. For “fastcap” I needed to set “DVIPSHEADERS” (to >> find “tex.pro”), “TFMFONTS” (for

bug#27217: texlive is too big

Peter Neidhardt writes: > What's the current status on this? No progress yet. I’ve been meaning to work on this, but it’s pretty tedious and demands concentration, which is a quality I haven’t been able to maintain. For most *packages* needing a subset of TeX

bug#27217: texlive is too big

What's the current status on this? I've tried processing an Org letter (http://orgmode.org/worg/exporters/koma-letter-export.html) and I get the following error: --8<---cut here---start->8---

bug#27217: texlive is too big

Ricardo Wurmus writes: > What’s missing? > > Currently, one needs to set a lot of environment variables to use these > separate packages. For “fastcap” I needed to set “DVIPSHEADERS” (to > find “tex.pro”), “TFMFONTS” (for compiled metafont files), “TEXFORMATS” > (for the

bug#27217: texlive is too big

Currently, we offer the complete texlive distribution in a single package that weighs several gigabytes. This causes several problems: * it’s much too heavy a dependency for packages * it takes a long time to download * it takes a long time to compress the substitute * a user who only wants to