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.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to