Opened 14 years ago
Closed 14 years ago
#25478 closed defect (fixed)
texlive-latex-recommended: beamer.cls depends on pgfcore.sty
Reported by: | jjstickel@… | Owned by: | drkp (Dan Ports) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.9.1 |
Keywords: | beamer pgf | Cc: | nerdling (Jeremy Lavergne) |
Port: | texlive-latex-recommended |
Description
I discovered that when using beamer.cls, which is included in texlive-latex-recommended, it requires pgfcore.sty, which is separately in texlive-pictures. One solution would be to make texlive-latex-recommended depend on texlive-pictures, but this may be a bit overkill. I suppose the real bug is upstream: beamer should be in latex-extra, which does depend on pictures, and not in latex-recommended. At the minimum, perhaps a warning or a note in the description could tell the user that pictures is also required if using beamer.cls.
Another option might be to depend on just the existing pgf port. However, I had this installed and the pgfcore.sty there was not found by latex (not sure why and do not have time to troubleshoot right now).
BTW, thanks for the updated texlive ports.
Jonathan
Change History (9)
comment:1 Changed 14 years ago by drkp (Dan Ports)
Cc: | dports@… removed |
---|---|
Owner: | changed from macports-tickets@… to dports@… |
Status: | new → assigned |
comment:2 follow-up: 7 Changed 14 years ago by drkp (Dan Ports)
comment:3 Changed 14 years ago by drkp (Dan Ports)
Replying to jjstickel@…:
Another option might be to depend on just the existing pgf port. However, I had this installed and the pgfcore.sty there was not found by latex (not sure why and do not have time to troubleshoot right now).
This should work OK (assuming the pgf port is up to date) but I haven't tried it yet.
comment:4 Changed 14 years ago by drkp (Dan Ports)
Cc: | snc@… added |
---|
I'm inclined to deal with this on a case-by-case basis, i.e. fix beamer/pgf and let the others be for now.
I want to make texlive-latex-recommended depend on the pgf port (and eventually pull pgf out of texlive-pictures), but it currently depends on texlive and that would create a dependency loop.
snc: what does pgf actually need to depend on? Would texlive-basic or texlive-latex work?
Could also fix this by making texlive-latex-recommended depend on texlive-pictures, but I'd rather avoid that if possible.
comment:5 follow-up: 6 Changed 14 years ago by nerdling (Jeremy Lavergne)
pgf requires texhash so it can refluff the hash upon installation. After that it should work just fine with tex backends such as pdftex and dvips. To that end, which do you find best out of all the packages that provide texhash?
comment:6 follow-up: 8 Changed 14 years ago by drkp (Dan Ports)
Replying to snc@…:
pgf requires texhash so it can refluff the hash upon installation. After that it should work just fine with tex backends such as pdftex and dvips. To that end, which do you find best out of all the packages that provide texhash?
If that's all it needs, mktexlsr/texhash is provided by texlive-bin, but you should probably depend on texlive-basic instead because texlive-bin doesn't provide a functional texlive installation by itself.
comment:7 Changed 14 years ago by drkp (Dan Ports)
Replying to dports@…:
To divide the texlive texmf blob into ports, we make a couple of assumptions about the TL package database. We assume that every CTAN package is contained in exactly one collection (each collection becomes one port). We also assume that, for each collection, the dependencies of all the CTAN packages in it are satisfied by the set of other collections that the collection depends on. (This is where the dependencies between ports come from.)
It turns out that the latter assumption is only almost true. beamer and pgf is the main exception but there are a handful of others:
The updated list of dependency irregularities for texlive 2010 appears to be:
- context (texlive-context) -> lm (texlive-fonts-recommended)
- context (texlive-context) -> xetex (texlive-xetex)
- context (texlive-context) -> mptopdf (texlive-metapost)
- context-games (texlive-context) -> skaknew (texlive-games)
- mltex (texlive-formats-extra) -> latex (texlive-latex)
- ctex (texlive-lang-cjk) -> ttfutils (texlive-fontutils)
- ptex (texlive-lang-cjk) -> latex (texlive-latex)
- lh (texlive-lang-cyrillic) -> ec (texlive-latex-recommended)
- montex (texlive-lang-mongolian) -> cbfonts (texlive-lang-greek)
- texpower (texlive-latex-extra) -> tpslifonts (texlive-fonts-extra)
- beamer (texlive-latex-recommended) -> pgf (texlive-pictures)
- pgf (texlive-pictures) -> xkeyval (texlive-latex-recommended)
- tikz-timing (texlive-pictures) -> svn-prov (texlive-latex-extra)
I am dealing with the beamer/pgf dependency by removing pgf from texlive-pictures and adding it as a dependency to texlive-pictures and texlive-latex-recommended.
I'm also adding texlive-xetex and texlive-metapost as dependencies to texlive-context, and texlive-latex as a dependency to texlive-formats-extra and texlive-lang-cjk.
I think the rest are probably safe to ignore, at least for now...
comment:8 Changed 14 years ago by drkp (Dan Ports)
Replying to dports@…:
Replying to snc@…:
pgf requires texhash so it can refluff the hash upon installation. After that it should work just fine with tex backends such as pdftex and dvips. To that end, which do you find best out of all the packages that provide texhash?
If that's all it needs, mktexlsr/texhash is provided by texlive-bin, but you should probably depend on texlive-basic instead because texlive-bin doesn't provide a functional texlive installation by itself.
I updated pgf in r73099 to depend on texlive-basic to provide texhash instead of the entire texlive metaport.
comment:9 Changed 14 years ago by drkp (Dan Ports)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Interesting. I was about to send the blame upstream until I took a closer look.
To divide the texlive texmf blob into ports, we make a couple of assumptions about the TL package database. We assume that every CTAN package is contained in exactly one collection (each collection becomes one port). We also assume that, for each collection, the dependencies of all the CTAN packages in it are satisfied by the set of other collections that the collection depends on. (This is where the dependencies between ports come from.)
It turns out that the latter assumption is only almost true. beamer and pgf is the main exception but there are a handful of others:
Adding dependencies is the obvious solution but does seem a bit overkill (and apparently would create a dependency loop for beamer and pgf). Will look into this further. It's worth checking if this is still true in the latest version upstream.