On Mon, 16 Sep 2013 20:33:15 +0200, Roland Smith wrote: > On Mon, Sep 16, 2013 at 01:57:51AM +0200, Polytropon wrote: > > On Sun, 15 Sep 2013 21:00:22 +0200, Roland Smith wrote: > > > Personally I don't think TeX is a good fit for the ports tree (because of > > > duplication of effort). > > I have to add that I think that the chosen strategy (provide a full port and a > minimal port) is a good balance between functionality and maintenance > workload.
This is a good approach for all cases where no custom configuration (being done by tlmgr) has been done, and it should work for most scenarios, I assume. > > In conclusion, that could be said about many other software > > that brings its own package management. > > More or less. Not all of those work equally well as tlmgr or the ports tree. Of course; think about pip, npm, and the like. The preferred goal of using tlmgr from the TeXLive distribution instead of installing it with the ports tree (or pkg) would be that it somehow at least records the existence of the TeXLive installation on the system. This causes ports depending on it _not_ to attempt any futile additional installation. > > Of course, LaTeX is > > a big and complex beast that TeXLive manages well (instead > > of the system-provided tools for managing the ports tree). > > In my opinion, a good _integration with_ the ports tree is > > important, so dependencies will be resolved properly (and > > you won't end up havong both TeXLive _and_ teTeX on your > > system for no particular need). > > The problem is that if you hand over the management of the TeXLive install to > tlmgr, the ports tree doesn't know and cannot know what is provided and what > is depended on... Correct. As I said, I'd suggest tlmgr could honor that case if it is run on FreeBSD and update the system records accordingly, so port management and pkg can work with that "foreign" installation as if it would have been a valid installation done with the system's default means. > > On the other hand, this > > might introduce demands of other "software compilations" > > to move their management out of the system's range, so we > > end up micro-managing many different sets of software in > > their own specific way, abandoning the centralized means > > of maintaining our software... > > There is indeed no silver bullet. True. However, a good integration with keeping an eye on the most obvious and important side effects could help. For example, the TEX_DEFAULT setting in /etc/make.conf is already a good beginning to select between teTeX and TeXLive. Maybe something similar could be added by tlmgr to satisfy port and package management tools with the illusion that everything went fine? :-) > > > Since TeXLive is very complete and > > > self-contained, I don't have other ports that depend on TeX. > > > > It's the port maintainers' task to take care of the proper > > declaration of dependencies, and for system tools to handle > > them. I don't think it is a big problem to make this consistent > > with how TeXLive handles things. > > It is not that simple. After every tlmgr run, you'd have to generate a new > plist for the port. Since TeXLive is contained in one directory tree > (/usr/local/texlive/<year>) that part is relatively simple. But tlmgr can also > install scripts or binaries. So after every tlmgr run, the list of binaries > that the port provides and the list of libraries or interpreters (ports) that > it requires would have to be updated. This is not trivial. I recognize that complicated task, but I would like to say that solving that problem (or at least "possible annoyance") would really benefit "both worlds" - TeXLive can be managed with tlmgr _and_ the system software records will keep working properly. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
