M.Canales.es wrote: > The "current" version remap is a catch-all for stock DB documents that don't > need to worry about the output tagging and look and are happy with the > defaults. On the other side, technical documentation that need a customized > tagging & > look on HTML and/or PDF output (i,e,. on-line documentation that should > follow the look of the web site or books destined to commercial printing) > relies on XSL/CSS customizations to can generate it. That approach depend on > the use of a well-known base DB-XSL version, thus the "current" version can't > be used in such cases. > >
OK. Now imagine the following situation: someone wants to create a Debian package with the LFS book. Debian policy requires that all HTML and PDF files are rebuilt from XML source in this case. If the LFS book relies on the external DocBook XSL setup of a certain version, I see no way to do it, except by reverting the switch to the external copy of DocBook XSL stylesheets (which is as bad as any other reversion of upstream changes) or changing the stylesheet version to "current" (which is going to break PDF - even worse). The problem is that old versions of DocBook XSL are simply not available as Debian packages, so one cannot build-depend on them without immediately getting a release-critical bug report. Maybe it makes sense, in the case of switching to the released version of DocBook XSL, to adopt a solution from argouml: * depend on a known (not "current") version of DocBook XSL * don't keep a copy of DocBook XSL in SVN (but maybe add to tarballs) * add a Makefile target for downloading the correct version of DocBook XSL * make it easy to use this private just-downloaded copy of stylesheets instead of the (possibly non-existent) system-wide installation -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
