Getting rid of texlive-texmf...

E

eldaemon

Of all of my ports, texlive-texmf is the giant in the room.1.8GB .tar.xz source.

It seems like it might end up getting pulled in installing docs for other packages. I'm not sure if there's one common package I can opt out of requiring texmf to get rid of it entirely.

Not even completely sure what it does. It's just obscenely big.

Have any of you went on a quest to purge it from your system without losing any good documentation formatting (or ability to build the freebsd-docs package) in the process?
 
Code: 
root@vacallinehae ~>  uname -r
12.1-RELEASE-p7
root@vacallinehae ~>  pkg info
dialog4ports-0.1.6             Console Interface to configure ports
pkg-1.14.6                     Package manager
root@vacallinehae ~>  cd /usr/ports/misc/freebsd-doc-en/
root@vacallinehae /usr/ports/misc/freebsd-doc-en> make
[…]
root@vacallinehae /usr/ports/misc/freebsd-doc-en>  make install
[…]
root@vacallinehae /usr/ports/misc/freebsd-doc-en>  pkg info | grep texlive
root@vacallinehae /usr/ports/misc/freebsd-doc-en>

As you can see: Building freebsd-doc-* doesn't pull in any texlive package. Nearly 200 new packages (and among of them really strange stuff like f.e. a sound lib and bash), but after a pkg autoremove none of them exists anymore: Not a single dependency.

Which of your "freebsd-docs package" rely on texlive-texmf?
 
I checked my latest repo build, and print/texlive-texmf is involved in a short dependency chain in my case:
Code: 
$ pkg options colord | grep MANPAGES
colord - MANPAGES: on
By default, the MANPAGES option of graphics/colord is disabled, so I just disabled the option, and my repo is now building without any dependency on print/texlive-texmf.

However, many other ports depend on print/texlive-texmf directly at build time via USE_TEX= …texmf or option_name_USE= …texmf without any option to avoid it unless explicitly noted:
If you build or install any of the ports in the (possibly incomplete) list above, then you will want to determine why those ports were required and trace the dependency chain while checking port options as I did above.

Once Poudriere started building packages, I saved a little time using json_pp(1) (installed as a part of lang/perl5.30), but I still had to manually trace the dependencies using each port's Makefile:
Code: 
json_pp < /usr/local/poudriere/data/logs/bulk/12amd64-default/2020-08-04T09:50:03Z/.data.json | less
 
I use TeX. It is a very small program and should not be a problem having it as dependency. The Bomb is the distribution TeX life.
 
There is a problem with LateX, texlive ,.... you can spend a lot of time to handpicking this and optimising that, but eventually you'll have to install nearly all of those single packages. Unless you have to work on very specific type of documents, N/A here and currently I don't have an example on top of my head, you'll end up installing the full package. Maybe I have not enough experience, or there are wrong concepts about the whole LateX/texlive thing in my head, but that's my personal experience.
[EDIT] you can look at it this way: LateX is as big as browser. Install it and forget it.
 
Yes, the issue in LaTeX is that document / module authors always drag in so many random dependencies just to do very simple things. It is almost as bad as Python's PIP.

the only difference is that many distributions of LaTeX basically bundle *all* the dependencies with them. It is almost like Python including the entire PIP (100s of GB) repo when you install it. I do prefer it this way because I don't need to fsck about online but it is rather large.

I suppose the real "issue" is that software developers are using LaTeX to write documentation. They should probably use more suited tools rather than an entire typesetting suite.
 
  • Like
Reactions: a6h
You must log in or register to reply here.
Back
Top