Re: [Clfs-dev] r7105
M.Canales.es wrote: The expected version is defined on the xsl:import statements placed on the top level stylesheets/ files (see the LFS-6.2 stylesheets for an example), and a sane system must not remap an explicit DB-XSL version to a different one via XML catalogs (that is fine for compatible DTDs releases, but never for XSL versions), thus that should not be an issue. Hm. Debian Lenny currently has only one version of DocBook XSL packaged (namely, 1.72.0 with Debian-specific changes). I am sure that there are some packages that build documentation using XSL. You are right that Debian does not remap DB-XSL versions via XML catalogs: $ grep xsl /etc/xml/catalog delegateURI uriStartString=http://docbook.sourceforge.net/release/xsl/; catalog=file:///etc/xml/docbook-xsl.xml/ delegateSystem systemIdStartString=http://docbook.sourceforge.net/release/xsl/; catalog=file:///etc/xml/docbook-xsl.xml/ $ cat /etc/xml/docbook-xsl.xml ?xml version=1.0? !DOCTYPE catalog PUBLIC -//OASIS//DTD XML Catalogs V1.0//EN file:///usr/share/xml/schema/xml-core/catalog.dtd catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog delegateURI uriStartString=http://docbook.sourceforge.net/release/xsl/; catalog=file:///usr/share/xml/docbook/stylesheet/nwalsh/catalog.xml/ delegateSystem systemIdStartString=http://docbook.sourceforge.net/release/xsl/; catalog=file:///usr/share/xml/docbook/stylesheet/nwalsh/catalog.xml/ /catalog $ cat /usr/share/xml/docbook/stylesheet/nwalsh/catalog.xml ?xml version=1.0 encoding=utf-8? catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog !-- XML Catalog file for DocBook XSL Stylesheets v1.72.0 -- !-- -- !-- *** adjusted for the Debian distribution *** -- rewriteURI uriStartString=http://docbook.sourceforge.net/release/xsl/current/; rewritePrefix=file:///usr/share/xml/docbook/stylesheet/nwalsh// rewriteSystem systemIdStartString=http://docbook.sourceforge.net/release/xsl/current/; rewritePrefix=file:///usr/share/xml/docbook/stylesheet/nwalsh// rewriteURI uriStartString=http://docbook.sourceforge.net/release/xsl/1.72.0/; rewritePrefix=file:///usr/share/xml/docbook/stylesheet/nwalsh// rewriteSystem systemIdStartString=http://docbook.sourceforge.net/release/xsl/1.72.0/; rewritePrefix=file:///usr/share/xml/docbook/stylesheet/nwalsh// /catalog The question is how they manage to continue building packages with documentation successfully when DocBook XSL is upgraded. For the gimp-help-2 package, the answer is that the current version of stylesheets is used by default, instead of the explicit number. If you know a package that doesn't use the current version, tell me its name, and I will look how Debian deals with this situation. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 08:43, Alexander E. Patrakov escribió: The question is how they manage to continue building packages with documentation successfully when DocBook XSL is upgraded. For the gimp-help-2 package, the answer is that the current version of stylesheets is used by default, instead of the explicit number. If you know a package that doesn't use the current version, tell me its name, and I will look how Debian deals with this situation. 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. They are not using customized XSL nor CSS layouts and are agnostics about what DB-XSL version is used to generate the docs. That is the normal approach used for DB documentation included in packages and by the API documentation generated by Doxygen. That allow graphical help systems, like Gnome or KDE help interfaces, to display the documentation pages with the same look for all packages via help browser embedded CSS code. Due changes on DB-XSL output code from version to version the look my differ from docs generated with one DB-XSL version to another if that CSS code is not adjusted, but that is not an issue for distros due that normally they use the same DB-XSL version for all packages (and its upgrades) across a stable distro version. 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. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
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
Re: [Clfs-dev] r7105
Alexander E. Patrakov wrote these words on 09/11/07 08:04 CST: 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. Pardon my ignorance to Debian procedures, but what exactly does create a Debian package mean? And so I can properly evaluate the situation as it pertains to going back to system-installed XSL Stylesheets, why does Debian policy affect anything we do in (B)LFS? 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). How have you been doing it for the last few *years* (up until just a month or so ago)? Why wasn't this an issue for the many years we used external XSL stylesheets? 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. Again, why do we care what is available as a Debian package? And why couldn't one just install whatever version of stylesheets that makes Debian happy and create a 'current' symlink pointing at it. A 'current' symlink won't affect anything in (B)LFS. 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 I'm lost here. I don't think I fully grasp what the problem is, and why we'd need to worry about any of this. We never had to worry about any of it before, and there was never an issue that I knew of (or perhaps there was, and it was never mentioned?). -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 08:19:01 up 7 days, 8:21, 1 user, load average: 0.11, 0.06, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 15:04, Alexander E. Patrakov escribió: 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). I don't see here an issue for us, but for distro packages creators. In any distro, when package A depend on version X of package B where X is not the default version for B on the target distro release version, then a package B-X that can be installed side-by-side without conflicts with the default package B is created. That has been true from always for autotools packages, back-ward compatibility libraries, libstdc++ versions needed to run closed binaries, etc. Why should it be diferent when related about DB-XSL versions? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
M.Canales.es wrote: El Martes, 11 de Septiembre de 2007 15:04, Alexander E. Patrakov escribió: 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). I don't see here an issue for us, but for distro packages creators. Yes, an issue for distro package creators, but caused by LFS upstream not willing to cooperate :) In any distro, when package A depend on version X of package B where X is not the default version for B on the target distro release version, then a package B-X that can be installed side-by-side without conflicts with the default package B is created. Yes, if such package is available. That has been true from always for autotools packages, back-ward compatibility libraries, libstdc++ versions needed to run closed binaries, etc. Why should it be diferent when related about DB-XSL versions? This is a question to distros, not to me. Anyway, there are no Debian packages with old docbook-xsl versions. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 15:04, Alexander E. Patrakov escribió: 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. Forgot to mention. That's a distro policy fault. DocBook XML DTDs or DocBook XSL styleshets versions are not exclusives. All available versions can be installed on a system without conflicts and should be availables if some source document request them. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 15:48, Alexander E. Patrakov escribió: Yes, an issue for distro package creators, but caused by LFS upstream not willing to cooperate :) Hu? What most cooperation is needed apart from saying on what external packages version our sources depends on? If someone what create, for example, a LFS-6.2 package for Debian Lenny, it know that must create also a DocBook-XSL-1.69.1 package, and maybe a current or patched tidy package, if not availables upstream. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
M.Canales.es wrote: Forgot to mention. That's a distro policy fault. DocBook XML DTDs or DocBook XSL styleshets versions are not exclusives. All available versions can be installed on a system without conflicts and should be availables if some source document request them. Would you mind if I report this to Debian as a bug, and CC: you so that you get a chance to answer the replies? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 16:09, Alexander E. Patrakov escribió: Would you mind if I report this to Debian as a bug, and CC: you so that you get a chance to answer the replies? If you ask about creating sepparate DB-XSL packages for each available version, and no other Debian package depends on a specific DB-XSL version, I think that the bug might be refused as WONTFIX saying that if you need a concret DB-XSL version you can create your own tarball or install it in your home dir. But if you ask about including into the Lenny release packages for LFS-6.2 and/or BLFS-6.2 (not LFS-6.3), if that inclusion is accepted then they will be forced to create also a DocBook-XSL-1.69.1 package. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
Randy McMurchy wrote:
Alexander E. Patrakov wrote these words on 09/11/07 08:04 CST:
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.
Pardon my ignorance to Debian procedures, but what exactly does
create a Debian package mean?
For Debian Developers, this means:
1) (Re)package the original source files into a tar.gz archive, rename
it according to the Debian requirements (something like
lfs-book_6.3+r7105.orig.tar.gz)
2) Patch the sources as needed to resolve bugs, etc.
3) Create a debian directory with the files that are used for creating
*.deb files from the above-mentioned source, plus various
Debian-specific mandatory documentation such as a packaging changelog.
The following set of files is typical:
debian/{changelog,compat,control,copyright,rules}. debian/rules is just
a Makefile (with #!/usr/bin/make -f at the top and the executable bit
set) with several mandatory targets (such as binary, which builds the
sources and packs the result into the deb packages). debian/control,
most importantly, lists the build-time and run-time dependencies.
4) Create a diff.gz between the freshly unpacked contents of orig.tar.gz
and the result of steps (2)+(3) above. I.e., the patch would contain
bugfixes plus the whole debian directory.
5) Create the dsc file from the debian/control file (using the
dpkg-buildpackage tool). This file contains build-time dependencies,
package version, the desired architectures, and MD5 sums of orig.tar.gz
and diff.gz files, all signed with GPG.
6) Upload the dsc, orig.tar.gz and diff.gz files to a buildd (a machine
that runs a build daemon). The daemon will automatically verify your
signature, create a chroot, populate it with the build-time dependencies
of your package, unpack it, apply the diff, and run debian/rules
binary. The resulting deb files are then automatically placed into the
archive.
And so I can properly evaluate
the situation as it pertains to going back to system-installed
XSL Stylesheets, why does Debian policy affect anything we do
in (B)LFS?
Strictly speaking, it doesn't. However, it would be nice if LFS
cooperates a bit more with packagers by making their job easier.
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).
How have you been doing it for the last few *years* (up until just
a month or so ago)?
I was not a Debian user then.
Why wasn't this an issue for the many years
we used external XSL stylesheets?
Because nobody attempted to create a package for other distros.
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.
Again, why do we care what is available as a Debian package? And
why couldn't one just install whatever version of stylesheets that
makes Debian happy and create a 'current' symlink pointing at it.
Because the buildd won't do it for you.
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
I'm lost here. I don't think I fully grasp what the problem is,
Most distro packages are autobuilt according to buildscripts. One cannot
specify a dependency on something (e.g., old version of docbook-xsl)
which is not packaged.
and why we'd need to worry about any of this.
Nothing beyond it would be nice to cooperate with packagers.
We never had to worry
about any of it before, and there was never an issue that I knew of
(or perhaps there was, and it was never mentioned?).
You are right - the issue always existed but was never mentioned.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
M.Canales.es wrote: What most cooperation is needed apart from saying on what external packages version our sources depends on? Make it easy to use a just-downloaded private copy of the correct version of the stylesheets. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
On 9/11/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote: M.Canales.es wrote: What most cooperation is needed apart from saying on what external packages version our sources depends on? Make it easy to use a just-downloaded private copy of the correct version of the stylesheets. Got a patch for that? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 16:30, Alexander E. Patrakov escribió: Make it easy to use a just-downloaded private copy of the correct version of the stylesheets. That is already done. You can place the stylesheets anywhere, just update the XML catalogs to point to that path when that version is requested. If you have no permissions to edit /etc/xml/catalog, you can create your own ~/xml/catalog and use it adding to your env XML_CATALOG_FILES=~/xml/catalog -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
M.Canales.es wrote: That is already done. You can place the stylesheets anywhere, just update the XML catalogs to point to that path when that version is requested. If you have no permissions to edit /etc/xml/catalog, you can create your own ~/xml/catalog and use it adding to your env XML_CATALOG_FILES=~/xml/catalog Thanks. I will try this and submit a documentation patch if it works. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Martes, 11 de Septiembre de 2007 17:06, Dan Nicholson escribió: FYI, this is a property of xsltproc(1), and not something native to LFS. Actually, it's an standard. All XML parsers should honour XML_CATALOG_FILES, the same that all SGML parsers should honour SGML_CATALOG_FILES -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
On 9/10/07, Randy McMurchy [EMAIL PROTECTED] wrote: Dan Nicholson wrote these words on 09/10/07 12:07 CST: Although both methods have their drawbacks, I prefer the current method of using a snapshot in the sources. That makes it more robust against different hosts since we can enforce the version of the stylesheets used. Not to argue, but for the sake of discussion, what does different hosts have to do with it? anduin, quantum, my host, your host... If any of us are using different stylesheets, then we might see different behavior in the rendered content. But more importantly, my point was that placing an entire 3rd party package into the (B)LFS sources does not conform to the whole philosophy of what our project tries to convey. That would be the drawback to this approach. If we do go back to using the host's stylesheets, then it should be completely clear in the sources (or somewhere else) what version is expected. Possibly we can check and enforce this in the Makefile. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
Dan Nicholson wrote these words on 09/10/07 12:26 CST: anduin, quantum, my host, your host... If any of us are using different stylesheets, then we might see different behavior in the rendered content. But is it *possible* to use different stylesheets? (see below) If we do go back to using the host's stylesheets, then it should be completely clear in the sources (or somewhere else) what version is expected. Possibly we can check and enforce this in the Makefile. I thought it already was. I thought that's what the xsl:import href=http://docbook.sourceforge.net/release/xsl/1.69.1/xhtml/docbook.xsl/ (or whatever the relevant version may be) line was for. Have I been mistaken about this all along? -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:39:00 up 6 days, 12:41, 1 user, load average: 0.07, 0.09, 0.13 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
Dan Nicholson wrote these words on 09/10/07 12:07 CST: Although both methods have their drawbacks, I prefer the current method of using a snapshot in the sources. That makes it more robust against different hosts since we can enforce the version of the stylesheets used. Not to argue, but for the sake of discussion, what does different hosts have to do with it? But more importantly, my point was that placing an entire 3rd party package into the (B)LFS sources does not conform to the whole philosophy of what our project tries to convey. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:15:01 up 6 days, 12:17, 1 user, load average: 0.17, 0.15, 0.17 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
El Lunes, 10 de Septiembre de 2007 19:26, Dan Nicholson escribió: That would be the drawback to this approach. If we do go back to using the host's stylesheets, then it should be completely clear in the sources (or somewhere else) what version is expected. Possibly we can check and enforce this in the Makefile. The expected version is defined on the xsl:import statements placed on the top level stylesheets/ files (see the LFS-6.2 stylesheets for an example), and a sane system must not remap an explicit DB-XSL version to a different one via XML catalogs (that is fine for compatible DTDs releases, but never for XSL versions), thus that should not be an issue. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Clfs-dev] r7105
On 9/10/07, M.Canales.es [EMAIL PROTECTED] wrote: El Lunes, 10 de Septiembre de 2007 19:26, Dan Nicholson escribió: That would be the drawback to this approach. If we do go back to using the host's stylesheets, then it should be completely clear in the sources (or somewhere else) what version is expected. Possibly we can check and enforce this in the Makefile. The expected version is defined on the xsl:import statements placed on the top level stylesheets/ files (see the LFS-6.2 stylesheets for an example), and a sane system must not remap an explicit DB-XSL version to a different one via XML catalogs (that is fine for compatible DTDs releases, but never for XSL versions), thus that should not be an issue. My fault. Scratch that comment. I have no objection to using the host's stylesheets, then. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
