On 10/29/2015 05:10 PM, Georg Baum wrote:
Richard Heck wrote:
If we support the added style, then users who both use that style and
use an older version of the package will have non-compilable documents.
So you could have a document that worked perfectly well, you make one
change---use the new style---and now it won't compile. What follows is a
frustrated message to the user list.
Good point, I did not think too much about that. However, it would be no
problem IMHO if there was an error message explaining that the compilation
did not work because of an outdated package. Then the user could easily
either update his TeX installation or refrain from using this style. This
would be similar to the error you get when the package is completely
missing. We could extend the layout file syntax so that a style can list its
minimum required package version, and then LyX could determine for each
installed package the version in chkconfig.ltx (if this is technically
possible, I did not check). Then LyX could give a meaningful error message.
Long-term, I think this sort of extension is exactly what we need. What
I do not know myself is how to get this information to LyX about what
versions of which packages the user has installed. Presumably, the
configuration script could find this info and we could put it into
txtlcass.lst or whatever. (Re-configuring after package updates will
thus become a good idea....) But I do not know how to do that. My TeX
skills do not reach that level. I try to stay away from chkconfig.ltx.
But even if we do that, then I think we should require that the new
layout to include preamble code that makes the output with an old
package equivalent to that with the new one, at least as far as the new
style is concerned. E.g.:
\ifundefined\phone{
\newcommand\phone{
% code borrowed from the new version....
}
}
There's a \providecommand, too, that is equivalent to this, right? Ugly
preamble stuff, to be sure, but useful, nonetheless, I think.
I would not do that. This would require to check the license of that code
which is often incompatible to the LyX license.
Yes, didn't think about that. And, longer-term, if we go as above, then
we don't need to do this.
I guess my question then is what to do shorter term. It seems a bit late
in the 2.2 cycle to do what we imagined above.
Richard
