Opened 6 years ago
Closed 4 years ago
#56734 closed defect (fixed)
dblatex @0.3.10_2 +mactex polutes texmf-local
Reported by: | rpspringuel (Fr. Samuel Springuel) | Owned by: | neverpanic (Clemens Lang) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.5.2 |
Keywords: | Cc: | nortcele, lemzwerg (Werner Lemberg) | |
Port: | dblatex |
Description
When installing dblatex +mactex, a series of symlinks are created in texmf-local to some out-of-date style files. More recent versions of these style files (in one case much more recent) are available in MacTeX already and so there is no need to install them. Indeed, installing them in this fashion is problematic as their placement in texmf-local means the more recent versions are not used by any documents compiled on the system.
The outdated style files are:
Style file MacTeX 2018 version package linked version attachfile.sty 2016/09/18 v1.9 2006/03/28 v1.2a bibtopic.sty 2006/09/08 v1.1a 2002/08/22 v1.0k enumitem.sty 2011/09/28 v3.5.2 2004/07/19 v1.0 lastpage.sty 2015/03/29 v1.2m 1994/06/25 v0.1b ragged2e.sty 2009/05/21 v2.1 2003/03/25 v2.04
Additionally dummyels.sty, unicode.sty, and xecyr.sty are available in MacTeX in the same versions as dblatex installs, so they aren't really needed either (though they don't create the same problem).
At the very least, a warning about these linked files should be included in the port's post-installation notes.
Attachments (1)
Change History (21)
comment:1 Changed 6 years ago by jmroot (Joshua Root)
Owner: | changed from cal@… to neverpanic |
---|
comment:2 Changed 6 years ago by neverpanic (Clemens Lang)
Status: | assigned → accepted |
---|
comment:3 Changed 5 years ago by neverpanic (Clemens Lang)
Cc: | nortcele lemzwerg added |
---|
comment:4 Changed 5 years ago by lemzwerg (Werner Lemberg)
Yes, dropping +mactex is probably the simplest solution – I added it only to make lilypond-devel build with an external TeX distribution; I don't have any further interest in this package :-)
However, I first have to fix lilypond (and lilypond-devel) to make dblatex optional.
comment:5 follow-up: 6 Changed 5 years ago by nortcele
Please don't drop the +mactex support, it is used and needed by users of the auto-multiple-choice port.
Last patches where supposed to verify, at the time of the port installation, the presence of a style file before adding the link. Can't do anything if mactex updates those files later.
comment:6 Changed 5 years ago by rpspringuel (Fr. Samuel Springuel)
Replying to nortcele:
Last patches where supposed to verify, at the time of the port installation, the presence of a style file before adding the link. Can't do anything if mactex updates those files later.
If that's what it was supposed to do, then it's failing. I've had a full version of MacTeX (which includes all these style files) installed on my computer continuously for years (updating each year with a new release) and had to clean-up texmf-local again recently (sometime within the past month or so) after dblatex polluted it again.
comment:7 Changed 5 years ago by lemzwerg (Werner Lemberg)
Samuel, do you have a log file of your dblatex installation? Or maybe can you retry to install dblatex to get one? The code to check for existing files in the Portfile is present even if you don't use +mactex
. Maybe there's a typo or thinko somewhere for the +mactex
variant that makes kpsewhich
not find the corresponding files.
comment:8 Changed 5 years ago by rpspringuel (Fr. Samuel Springuel)
I just tried reinstalling dblatex but the log file wasn't preserved (as the port thinks it installed cleanly). Even when using -tvd
flags the logfile is not preserved. Is there some other flag I should use to keep the log file after a successful install?
comment:9 follow-ups: 10 11 Changed 5 years ago by neverpanic (Clemens Lang)
-k
keeps the log. Alternatively, run port destroot
instead of install and look at $(port work dblatex)/destroot
for a list of files that would be installed without actually installing them.
I haven't looked at the code again, but if the Portfile currently looks at the user's system to decide what files to install, that's wrong. It should not be doing that, because it means that the same port with the same variants might look different on different user's systems. We currently don't distribute binaries for non-default variants by default, but if we did (or we'd build one for dblatex +mactex because something depends on it), users might end up installing a binary package that was created according to what the buildbot's filesystem looks like.
Why are we duplicating files shipped by MacTeX anyway? Shouldn't we instruct users to fix their MacTeX installation if it does not provide the required files, rather than attempting to fix it for them automagically?
comment:10 Changed 5 years ago by rpspringuel (Fr. Samuel Springuel)
Replying to neverpanic:
-k
keeps the log. Alternatively, runport destroot
instead of install and look at$(port work dblatex)/destroot
for a list of files that would be installed without actually installing them.
Yeah, still no log file to be found by port log dblatex
or port logfile dblatex
after a new installation. I'll attach the output of port contents dblatex
(as a quick glance seems to indicate it's the same as what I find in destroot).
Why are we duplicating files shipped by MacTeX anyway? Shouldn't we instruct users to fix their MacTeX installation if it does not provide the required files, rather than attempting to fix it for them automagically?
That would be my preferred solution.
Changed 5 years ago by rpspringuel (Fr. Samuel Springuel)
Attachment: | dblatex_contents.txt added |
---|
comment:11 Changed 5 years ago by nortcele
Replying to neverpanic:
I haven't looked at the code again, but if the Portfile currently looks at the user's system to decide what files to install, that's wrong. It should not be doing that, because it means that the same port with the same variants might look different on different user's systems. We currently don't distribute binaries for non-default variants by default, but if we did (or we'd build one for dblatex +mactex because something depends on it), users might end up installing a binary package that was created according to what the buildbot's filesystem looks like.
Well, with the +mactex variant, those style files are installed out of the Macports hierarchy. And MacTex tools could also change data here so anyway this space might look different on different user's system.
I'll try to test installation of a dblatex +mactex variant to see what's happening here.
comment:12 Changed 5 years ago by nortcele
The test to detect the presence of a style in the Texlive installation that worked before does not work anymore. At least under MacOS 10.12.6 (MacPorts 2.6.2, Xcode 9.2) with MacTex 2020. I'm still digging into the problem.
comment:13 Changed 5 years ago by nortcele
There is a bug in the test part of the Portfile. I'll propose a correction.
The line
if {[catch {exec ${prefix}/bin/kpsewhich -a [file tail $f]} result]} {
Should bie
if {[catch {exec ${dblatex.mactex_bin}/kpsewhich -a [file tail $f]} result]} {
I tested the modified Portfile with macOS 10.12.6 (MacPorts 2.6.2, Xcode 9.2) with MacTex 2020. I have yet to test another installation with a different version of macOS.
comment:14 Changed 5 years ago by nortcele
Commited pull request https://github.com/macports/macports-ports/pull/7066 to solve the problem.
comment:15 Changed 5 years ago by neverpanic (Clemens Lang)
The point remains: MacPorts should never touch files installed using a different package manager. This leads to all sorts of unexpected behavior. For example, let us assume you install dblatex +mactex, that puts a couple of files into your /usr/local/texlive
, the enduser uses whatever tool manages that installation to update that installation to a newer version, the user uninstalls dblatex. Suddenly those files are gone, while the metadata potentially kept by the MacTeX package management expects them to be present and at a certain version.
The more I think about this, the less I think this is a good solution. Could we not just add a check during post-activate for the expected files, and if they're missing, print instructions telling users how to install them using MacTeX?
comment:16 Changed 5 years ago by nortcele
Other ports with +mactex variant allready do that. i.e. latexml. That the way to add functionnalities to TexLive. So all mactex variants should be suppressed.
comment:17 Changed 5 years ago by rpspringuel (Fr. Samuel Springuel)
The problem here isn't with adding functionalities, but rather with regressive ones. I'm fine with +mactex ports adding their own style files to texmf-local[*] because texmf-local is not maintained by MacTeX (that's texmf-dist), but rather a directory provided specifically for non-MacTeX maintained files to be installed. However, because texmf-local has priority over texmf-dist, dblatex creates a problem when it adds style files that it doesn't maintain (or even sync with the latest version) but which it considers to be prerequisites for its own style files. It is not touching the MacTeX maintained files, but by installing these unmaintained prerequisites in a location which has priority over the MacTeX maintained files, the maintained files are not seen by latex et al. when compiling documents. IMHO, ports should not be adding files to the system (be that in a MacPorts specific location or in the texmf-local tree) that they are not actually maintaining. If I'm using MacTeX to maintain those prerequisites (in texmf-dist), then +mactex ports should, at most, warn me about those prerequisites and indicate that I should use MacTeX to make sure they are available.
[*]It is possible for MacPorts to not add to texmf-local, but maintain its own texmf tree (as it probably does for the texlive* ports). In that case, +mactex variants should provide instructions like these, directing users as to how to add the MacPorts texmf tree to their MacTeX installation.
comment:18 Changed 5 years ago by neverpanic (Clemens Lang)
Aren't those outdated files shipped by dblatex upstream? If so, then I guess we should consider this a bug in dblatex upstream whenever it happens, and they should update them to their latest versions.
Or, we need a different version of the +mactex variant that basically does nothing other than printing a note to explain how users have to install the required dependencies in MacTeX manually.
I'm inclined to merge https://github.com/macports/macports-ports/pull/7076 because it fixes the initial issue, at least if you already have the dependencies installed at the time you install the dblatex port. It's still not a great solution, but it seems the +mactex variant is always going to have this issue one way or the other.
comment:19 Changed 4 years ago by nortcele
@Clemens: I'm inclined to for merging https://github.com/macports/macports-ports/pull/7076 :-)
comment:20 Changed 4 years ago by nortcele
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
The +mactex support was provided by a contribution in #55106 and https://github.com/macports/macports-ports/pull/2579.
Maybe they are interested in fixing it – personally, I'd just drop it instead of attempting to fix this.