Texlive: split texmf part into its own recipe #6115

jmairboeck · 2021-08-07T12:07:13Z

This allows the texmf part to be a real "any" package without the secondaryArchSuffix as part of the package name.

Other changes:

make a debuginfo package for the main package (instead of using make install-strip)
fix tests for the main package
add missing fixPkgConfig
the /packages-path hack has been solved differently in the texmf package, not using kpsewhich anymore at all during install-tl. Because the paths are different in the second recipe, this doesn't work any more.
move fmtutil-sys --all (and updmap-sys) into a post-install script for the same reason
remove the copying of the tlpkg/README file which is missing somehow

Begasus · 2021-08-08T13:42:19Z

Checking builds atm and will report back later :)

Begasus · 2021-08-08T14:05:45Z

Checked a build for a sample.tex file in TeXstudio, didn't work (for the base install) needs checking on what's missing here :)

Begasus · 2021-08-08T17:13:09Z

Looks like the sample I used had some graphics in it, a plain tex file worked fine with the base package (without installing the texlive_texmf package)

jmairboeck · 2021-08-08T18:30:40Z

I am surprised that even anything works without the texlive_texmf package ...

When trying to build LilyPond without it, it seems to hang when invoking mf (MetaFont), but I still have to investigate it what happens exactly.

jmairboeck · 2021-08-09T12:18:47Z

When trying to build LilyPond without it, it seems to hang when invoking mf (MetaFont), but I still have to investigate it what happens exactly.

It says that it can't find the input file mfplain and asks interactively for another one instead. So it seems Llilypond requires at least that to build.

jmairboeck · 2021-08-29T14:07:20Z

I have now further split the texlive_texmf package into individual packages per "collection" (runtime, source and documentation files each), plus a "full" metapackage that depends on all collection packages.

jmairboeck · 2021-08-29T14:57:10Z

app-text/texlive_texmf/additional-files/createSubpackageInfos.pl

+		print "SUMMARY_$collection=\"TeXLive Collection: $shortdesc\"\n";
+		print "DESCRIPTION_$collection=\"$longdesc\"\n" if $longdesc;
+		print "PROVIDES_$collection=\"\n";
+		print "\ttexlive_texmf_$collection = \$portVersion\n";


Should we add PROVIDES for the individual TeX packages in the collection here as well, so that other packages can later depend on them instead of just the whole collection?

How should these be called? Should (or can) we introduce a new prefix (e.g. "tex:")?

Note: I would only do this for the runtime files. This is where it makes the most sense.

The generated file would become ca. 4000 lines longer. I have already implemented it locally but not tested yet.

jmairboeck · 2021-08-29T15:00:12Z

@korli has suggested in the forum to only make one subpackage for runtime, docs and source files per collection, and not 3 separate ones. What do you think?

jmairboeck · 2021-08-29T15:04:31Z

The biggest collection is "fontsextra" at 724.4 MiB (runtime files), the docs for this are 114.67 MiB, the sources 15.6 MiB. Putting these together would amount to 854.67 MiB.

jmairboeck · 2021-08-29T16:31:54Z

app-text/texlive_texmf/additional-files/createSubpackageInfos.pl

@@ -0,0 +1,95 @@
+#!/bin/perl
+


Should I add a license header here?

As to which one, I suppose it would have to be GPL v2 because it depends on such code. But I am open to MIT too, if that is possible.

jmairboeck · 2021-08-29T16:32:25Z

app-text/texlive_texmf/additional-files/getPackageEntries.pl

@@ -0,0 +1,34 @@
+#!/bin/perl
+


License header here too?

jmairboeck · 2021-08-29T16:37:17Z

I am thinking about swapping the names around, calling the texlive recipe "texlive_bin" and texlive_texmf just "texmf". The collection packages could be called "texlive_collection_$foo" too. Which would also solve the problem of what the PROVIDES for other packages should be called if we decide to do that. They could just use "texlive_$packagename" and no new prefix would be needed.

jmairboeck · 2021-08-29T19:06:47Z

app-text/texlive_texmf/texlive_texmf-2021.recipe

+	texlive_postinstall.sh
+	"
+
+POST_INSTALL_SCRIPTS="$relativePostInstallDir/texlive_postinstall.sh"


this doesn't work as such now. When only texlive_texmf is installed (no collection subpackages), it fails because something is missing apparently. I suppose it should at least be moved to the _basic subpackage. Ideally it should be called whenever one of the runtime subpackages is installed, but only once if multiple are installed at the same time.

However, this needs a bit more advanced logic because there are no post-transaction scripts in Haiku (like %posttrans in RPM).

waddlesplash · 2021-08-31T20:34:38Z

This should fix #1767 once merged.

korli · 2021-09-01T19:39:38Z

The biggest collection is "fontsextra" at 724.4 MiB (runtime files), the docs for this are 114.67 MiB, the sources 15.6 MiB. Putting these together would amount to 854.67 MiB.

Seems correct seeing the size at https://archlinux.org/packages/extra/any/texlive-fontsextra/
You can make one exception in your generating script, if that makes sense to you.

korli · 2021-09-01T19:46:46Z

I am thinking about swapping the names around, calling the texlive recipe "texlive_bin"

The _bin suffix (at Haikuports) generally means the package is repacked from a binary archive and not built from sources.

jmairboeck · 2021-09-01T19:53:18Z

Adding a special exception feels like a "hack" to me. Right now, the script doesn't even assume which collections exist at all but rather use the API function to get the list of available collections. So it will "just work" for future updates if the list changes.

Also, IMHO, the "average user" (or other downstream packages) probably won't need the sources, and to just compile documents you also don't need the documentation. So I think there are arguments for keeping them separate. The biggest advantage of only one package is of course having fewer packages (and fewer build packages to generate).

The sizes are file sizes of the actual .hpkg files as reported by Tracker.

korli · 2021-09-01T20:02:06Z

Adding a special exception feels like a "hack" to me. Right now, the script doesn't even assume wh

This recipe is a hack anyway, the generating script will need to be maintained. Do other repositories split Texlive the same? I see Arch is doing differently, why?

jmairboeck · 2021-09-01T20:09:31Z

Debian seems to separate the documentation too: https://packages.debian.org/search?keywords=texlive&searchon=names&suite=stable&section=all

korli · 2021-09-01T20:14:43Z

Debian seems to separate the documentation too

OK do we agree to use debian way of splitting the Texlive package then? So that we have a reference to follow, for naming and dependencies.

jmairboeck · 2021-09-01T20:39:04Z

I think following Debian would not be the worst choice. It seems that their main package maintainer is rather involved upstream too (if I am not mistaken). At least Debian is the only distro that links to an internal page on the official website.

But they too have a whole repository with quite a few scripts and other complex infrastructure to build the packages. https://github.com/debian-tex/texlive-nonbin
I don't think we need or should use something that complex.

Also, I think you were mistaken about Arch: https://wiki.archlinux.org/title/TeX_Live#Package_documentation

Note that I am not completely against using single packages for runtime files, docs and sources, I just think that most users probably won't need the latter. If you or others still think that it is better with "consolidated" packages, I can also change that. I'm just not really convinced, and the current implementation works too.

korli · 2021-09-01T20:54:48Z

If packaging docs and sources can be skipped, why not doing the same?

jmairboeck · 2021-09-04T14:57:20Z

I am thinking about swapping the names around, calling the texlive recipe "texlive_bin"

The _bin suffix (at Haikuports) generally means the package is repacked from a binary archive and not built from sources.

Debian calls the package "texlive-binaries". Would that be a suitable name?

Begasus · 2021-09-18T08:58:56Z

Maybe it's time to create a seperate texlive_texmf PR for this, so far the base packages provide the needed binaries (afaikt) for TexStudio?

jmairboeck · 2021-09-18T10:06:34Z

I have removed the texlive_texmf splitting into a new branch (PR will come later) so that this can be merged now and at least the main package can be provided in HaikuDepot soon (although it will mostly not work without the other package).

The former main package has been renamed to texlive_core to reflect Gentoo's naming. The texmf package is now just called "texlive".

this is to save the work on GitHub for now

…name) and texlive_texmf to texlive This leads to better names when splitting the texlive package later. Also, enable the texlive_core package to be built by buildmaster ;-)

jmairboeck · 2021-09-18T10:18:38Z

I have rebased the branch to resolve the conflict because of #6189.

I think this can be merged now (I have not tested the renamed package though).

jmairboeck · 2021-09-19T12:07:13Z

This should fix #1767 once merged.

This will not be fixed (any more) with this PR but with a follow-up which contains the actual split into multiple subpackages.

Begasus · 2021-10-02T08:04:29Z

@korli @waddlesplash do you think we can merge in it's current state?

korli · 2021-10-02T09:02:30Z

I'm afraid, I lost the thread on this PR, so from my point of view, no objection.

Begasus · 2021-10-03T06:09:17Z

Merging (after some talks here and on IRC so @jmairboeck can go along with the work on splitting up the correct packages.

Begasus added the wip-no-merge label Aug 8, 2021

jmairboeck commented Aug 29, 2021

View reviewed changes

app-text/texlive_texmf/additional-files/getPackageEntries.pl Outdated

@@ -0,0 +1,34 @@

#!/bin/perl

Copy link

Member Author

jmairboeck Aug 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

License header here too?

jmairboeck commented Aug 29, 2021

View reviewed changes

jmairboeck force-pushed the texlive_texmf branch from 488495c to 50595f4 Compare September 18, 2021 10:02

jmairboeck added 3 commits September 18, 2021 12:09

texlive: split texmf into its own recipe (WIP)

056879b

this is to save the work on GitHub for now

texlive_texmf: fix recipe

9ef991f

texlive: rename binaries package to texlive_core (following Gentoo's …

bf40aca

…name) and texlive_texmf to texlive This leads to better names when splitting the texlive package later. Also, enable the texlive_core package to be built by buildmaster ;-)

jmairboeck force-pushed the texlive_texmf branch from 50595f4 to bf40aca Compare September 18, 2021 10:14

jmairboeck added 4 commits September 18, 2021 14:04

remove useless libtool files

3a5ed1e

texlive: add missing haiku REQUIRES

aa5402f

make texlive recipe more architecture agnostic

9340c30

fix name of debuginfo package

d0645cf

add more replacements for kpsewhich invocations by install-tl

020e4c6

Begasus removed the wip-no-merge label Oct 3, 2021

Begasus merged commit f1e832b into haikuports:master Oct 3, 2021

jmairboeck deleted the texlive_texmf branch October 3, 2021 08:54

jmairboeck mentioned this pull request Oct 3, 2021

texlive: split the package into multiple subpackages #6229

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Texlive: split texmf part into its own recipe #6115

Texlive: split texmf part into its own recipe #6115

jmairboeck commented Aug 7, 2021

Begasus commented Aug 8, 2021

Begasus commented Aug 8, 2021

Begasus commented Aug 8, 2021

jmairboeck commented Aug 8, 2021

jmairboeck commented Aug 9, 2021

jmairboeck commented Aug 29, 2021

jmairboeck Aug 29, 2021 •

edited

jmairboeck commented Aug 29, 2021

jmairboeck commented Aug 29, 2021

jmairboeck Aug 29, 2021

jmairboeck Aug 29, 2021

jmairboeck commented Aug 29, 2021

jmairboeck Aug 29, 2021 •

edited

waddlesplash commented Aug 31, 2021

korli commented Sep 1, 2021

korli commented Sep 1, 2021

jmairboeck commented Sep 1, 2021 •

edited

korli commented Sep 1, 2021

jmairboeck commented Sep 1, 2021

korli commented Sep 1, 2021

jmairboeck commented Sep 1, 2021

korli commented Sep 1, 2021

jmairboeck commented Sep 4, 2021

Begasus commented Sep 18, 2021

jmairboeck commented Sep 18, 2021

jmairboeck commented Sep 18, 2021

jmairboeck commented Sep 19, 2021

Begasus commented Oct 2, 2021

korli commented Oct 2, 2021

Begasus commented Oct 3, 2021

Texlive: split texmf part into its own recipe #6115

Texlive: split texmf part into its own recipe #6115

Conversation

jmairboeck commented Aug 7, 2021

Begasus commented Aug 8, 2021

Begasus commented Aug 8, 2021

Begasus commented Aug 8, 2021

jmairboeck commented Aug 8, 2021

jmairboeck commented Aug 9, 2021

jmairboeck commented Aug 29, 2021

jmairboeck Aug 29, 2021 • edited

Choose a reason for hiding this comment

jmairboeck commented Aug 29, 2021

jmairboeck commented Aug 29, 2021

jmairboeck Aug 29, 2021

Choose a reason for hiding this comment

jmairboeck Aug 29, 2021

Choose a reason for hiding this comment

jmairboeck commented Aug 29, 2021

jmairboeck Aug 29, 2021 • edited

Choose a reason for hiding this comment

waddlesplash commented Aug 31, 2021

korli commented Sep 1, 2021

korli commented Sep 1, 2021

jmairboeck commented Sep 1, 2021 • edited

korli commented Sep 1, 2021

jmairboeck commented Sep 1, 2021

korli commented Sep 1, 2021

jmairboeck commented Sep 1, 2021

korli commented Sep 1, 2021

jmairboeck commented Sep 4, 2021

Begasus commented Sep 18, 2021

jmairboeck commented Sep 18, 2021

jmairboeck commented Sep 18, 2021

jmairboeck commented Sep 19, 2021

Begasus commented Oct 2, 2021

korli commented Oct 2, 2021

Begasus commented Oct 3, 2021

jmairboeck Aug 29, 2021 •

edited

jmairboeck Aug 29, 2021 •

edited

jmairboeck commented Sep 1, 2021 •

edited