Am 18.05.2008 um 20:42 schrieb Benjamin Reed: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Ridgway wrote: > | When I tried to do something like this I was shot down; told that > the > | fink core team was reconsidering the whole issue of "system-" > | packages, and that, specifically, system-texlive was NOT going to > | happen. I then started an effort to package TeX Live in such a way > | as to make it fink-friendly. This failed miserably because TeX Live > | is (apparently) not built in a straightforward way, and the TeX Live > | people don't make it easy to get the tools with which they build it. > | If any of the above has changed I would love to see it. It is > totally > | ridiculous that the only TeX in Fink is tetex, which is ancient and > | dead. > > ~From what I understand, the previous attempts were to try to make it > work like existing system-tex, which is the issue. The issue is that > they're all different and have slightly different stuff.
Exactly. Even if we made a system-texlive package, it would *not* be correct for it to "Provide: tetex-base" or something like that -- stuff which actually depends on *tetex* being present, as opposed to texlive, would break. But packages which only need to invoke TeX, e.g. during their build phase to typeset stuff (like doxygen and others), or which simply want to use e.g. "latex" during runtime (like dblatex, latexmk, etc.) simply need those tools to be present inside your PATH (well, and usable, and some bits more, but you get the idea). > My impression of what Max is trying to do is to get away from the > monolithic "this represents tex" stuff that causes all of these > incompatibilities/differences in the first place and break it down to > providing "point" tools for individual features of tex that you need. > This seems like a reasonably future-proof approach. That would be my hope, too. Note, thoughl that not the splitting up is the crucial part here, I think, but rather the introduction of a way to distinguish between high-level TeX stuff being present and usable (i.e. mostly being able to invoke latex, tex, pdf(la)tex, epstofig, and various others) on the one hand, and TeX distro specific stuff (like being able to install TeX addons, like jadetex or foiltex). The former should work with virtually any TeX distro. The latter of course would be distro specific. So, my approach would make it possible to build doxygen with *any* sane TeX distro installed, no matter by which means, (as long as it is in PATH, or alternatively, as long as we provide a system-FOO package for it -- which would be easy to create and maintain, though). Package which want to install tetex addons would NOT magically work with texlive with this, but that is not to be expected, and is not my goal (I am not even sure I would recommend to anybody to try to go for that -- but that's another story). > > > Keep in mind, too, that this is just my opinion, and perhaps there are > other reasons not to do it that I'm not aware of, but from what I > understood, the reason there's been so much pushback is that adding a > "system-texlive" package doesn't solve our tex problems, it just adds > another. > > Whereas, breaking tex up into individual features seems more likely to > cause less trouble in the future, BUT, it requires someone willing to > know all sides of the tex equation enough to keep those things in > check... I don't claim to be know "all sides of the tex equation", but I am a quite proficient TeX user, and also know Fink a bit, so i would be willing to give it a try. The main stumbling block, as usual, will be my lack of time in general... But since this one bugs me personally, I would be willing to invest quite some. This would mostly mean: * Determine which packages use (te)TeX, and how * come up with a suitable list of new virtual packages * write a system-mactex / system-texlive package to match this scheme * extend Fink's tetex to the scheme * also extend system-tetex, though I have no means to test it; same for ptex * modify all my TeX-using packages to use the scheme * try to modify some of the other affected packages (like foremost doxygen, the pkg which got me started on this ;). This would end up as a big patch to the dists tree (I guess I could make a branch for this, but I believe it will be easier for me to maintain this as a patch first, working with both regular and pangocairo CVS). Oh, and in theory, the transition should be smooth: Pkgs could still use the old scheme, so it would be OK for maintainers of TeX-using packages to take some time to adjust..... Well, except for the usual virtual-pkg-headaches, which lurk just around the corner and which I probably do not yet fully appreciate, I guess ;). Clearly, if I get that far, I would need people to test this for me, resp. review what I did. Cheers, Max ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
