<div dir="ltr">On Sat, Nov 12, 2016 at 6:43 PM, Karl Berry <span dir="ltr"><<a href="mailto:karl@freefriends.org" target="_blank">karl@freefriends.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Hironobu,<br>
<span class="gmail-"><br>
For example, newtx depends on kastrup,<br>
<br>
</span>aka binhex.tex. Somewhat surprising to me, but ok, I see it.<br>
I added it.<br>
<span class="gmail-"><br>
and luatexja depends on filehook.<br>
<br>
</span>But, at least at a glance, only if array is not already loaded.<br>
<br>
Therefore I would not recommend that luatexja unconditionally depend on<br>
filehook -- one such case might not matter, but imagine if every package<br>
listed every other package that it *might* load, across all engines and<br>
all formats. You might as well install everything in the first place and<br>
be done with it. Which is, not coincidentally, already the default.<br>
<br>
As I've said before, conditional dependencies in the TeX world seem like<br>
a problem beyond the state of the art. Debian's "weak depends" would not<br>
be helpful, and I don't know of anything in practice that's gone beyond<br>
that. It seems to me the only true solution is to load packages at<br>
runtime a la MiKTeX, and that is an unsolved (and not easy) problem for TL.<br>
New developers welcome :).<br>
<span class="gmail-"><br>
it's getting harder and harder to set all<br>
dependencies correctly by hand.<br>
<br>
</span>It's no harder than it ever was: it's always been impossible, and it<br>
will remain impossible :). It is not and cannot be a goal to list every<br>
dependency. It's delusionary to think it can be done.<br></blockquote><div><br></div><div>For the majority of "use cases", you just want a way to ensure that packages <br>(with the appropriate version) needed for a specific task are installed. <br></div><div>Most users at my institute have either MiKTeX or a linux distro's telxlive<br></div><div>package. MikTeX's on-the-fly package loading is nice when you have<br></div><div>Internet access, but users often want to work on documents in off-hours<br></div><div>while at sea or in the field with either zero or expensive Internet access.<br></div><div>They start with some existing template that worked on their desktop,<br></div><div>only to find that some packages are missing or outdated on the laptop<br></div><div>in the field. <br></div><div><br></div><div>The majority of these cases start with a publisher's journal or report <br>style/class. Maybe it makes sense to have meta-packages for these <br>journal or report styles/classes. <br></div><div><span class="gmail-"></span><br><span class="gmail-"></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
seems to be resolved manually by TeX Live team in some cases<br>
<br>
</span>It is effectively the authors (and users) who do it now -- they send<br>
dependency information (like you just did), I (and Christian for MiKTeX<br>
I suppose) add dependencies as is useful.<br>
<br>
I have nothing in principle against the proposed CTAN field, as long as<br>
it used for unconditional dependencies. Meaning something the package<br>
requires every time it is loaded, with any engine. Anything other than<br>
that is a slippery slope that will lead to more problems than benefit,<br>
as far as I can see.<br>
<br>
There are various possibilities for automatically determining<br>
dependencies, going along autotesting packages. For example,<br>
auto-creating a minimal document, running with -recorder (across<br>
engines), and going through the output. It's an easy idea to have, not<br>
such an easy idea to find time to actually implement. --best, karl.<br></blockquote><div><br></div><div>This is really best done by maintainers of packages like a journal or<br></div><div>report style/class, but as you indicate, tracking dependencies is not <br></div><div>practical so it has to done by providing lists of packages <br></div><div>required, recommended, or suggested (e.g., commonly used by<br></div><div>authors) for use with a specific class. <br><br></div><div>Now that MiKTeX has repackaged things to be closer to texlive,<br></div><div>such lists might be useful on both texlive and MiKTeX. <br></div></div><br>-- <br><div class="gmail_signature">George N. White III <<a href="mailto:aa056@chebucto.ns.ca" target="_blank">aa056@chebucto.ns.ca</a>><br>Head of St. Margarets Bay, Nova Scotia</div>
</div></div>