I am writing an ebuild for a package that uses asciidoc to generate documentation in epub format. a2x can accomplish for this operation by using the "-f epub" option but this requires that a local style sheet is installed with app-text/docbook-xsl-stylesheets. app-text/docbook-xsl-stylesheets can support epub version 2 and 3 but asciidoc is only able to generate version 2. If the local style sheet is not installed this is the error that appear when a2x calls xsltproc: $ xsltproc --nonet --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/usr/share/asciidoc/docbook-xsl/epub.xsl" <path_to_the_xml_file.xml> warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/epub/docbook.xsl" compilation error: file /usr/share/asciidoc/docbook-xsl/epub.xsl line 12 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/epub/docbook.xsl xsltproc should be able to access remote files but I don't understand why it fails. Nevertheless it could use a local version installed by app-text/docbook-xsl-stylesheets[ruby]. The same problem have been already discussed in: * http://francisshanahan.com/index.php/2011/fixing-epub-problem-docbook-xsl-asciidoc-a2x/ * https://bugs.archlinux.org/task/22746?project=1&string=docbook-xsl My new package depends directly only on app-text/asciidoc which requires app-text/docbook-xsl-stylesheets. An hack would be to add a fake dependency to app-text/docbook-xsl-stylesheets[ruby] into the new ebuild I am writing. In my opinion there could be two actions to improve portage support: * rename the ruby useflag in IUSE of app-text/docbook-xsl-stylesheets to epub because it doesn't add ruby support but enable or not the installation of a ruby script used to do the conversion to epub format * add an epub useflag also to app-text/asciidoc to be able to propagate the correct useflag also to its dependency app-text/docbook-xsl-stylesheets, in this way the above mentioned hack is not needed I am not an expert of xsltproc at all so maybe there is a better explanation of what happens and then another solution. What do you think?
(In reply to Fabio Rossi from comment #0) > I am writing an ebuild for a package that uses asciidoc to generate > documentation in epub format. a2x can accomplish for this operation by using > the "-f epub" option but this requires that a local style sheet is installed > with app-text/docbook-xsl-stylesheets. > > app-text/docbook-xsl-stylesheets can support epub version 2 and 3 but > asciidoc is only able to generate version 2. If the local style sheet is not > installed this is the error that appear when a2x calls xsltproc: > > $ xsltproc --nonet --stringparam callout.graphics 0 --stringparam > navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics > 0 "/usr/share/asciidoc/docbook-xsl/epub.xsl" <path_to_the_xml_file.xml> > > warning: failed to load external entity > "http://docbook.sourceforge.net/release/xsl/current/epub/docbook.xsl" > compilation error: file /usr/share/asciidoc/docbook-xsl/epub.xsl line 12 > element import xsl:import : unable to load > http://docbook.sourceforge.net/release/xsl/current/epub/docbook.xsl > > xsltproc should be able to access remote files but I don't understand why it > fails. I skimmed through the a2x and xsltproc man pages, and found out that the problem here is the --nonet option, which I don't see any way to override. Not that it would help you in your ebuild, because I believe the portage sandbox would block network access anyway. > Nevertheless it could use a local version installed by > app-text/docbook-xsl-stylesheets[ruby]. > > The same problem have been already discussed in: > > * > http://francisshanahan.com/index.php/2011/fixing-epub-problem-docbook-xsl- > asciidoc-a2x/ > * https://bugs.archlinux.org/task/22746?project=1&string=docbook-xsl > > My new package depends directly only on app-text/asciidoc which requires > app-text/docbook-xsl-stylesheets. An hack would be to add a fake dependency > to app-text/docbook-xsl-stylesheets[ruby] into the new ebuild I am writing. I don't really consider that a hack, see below. > In my opinion there could be two actions to improve portage support: > > * rename the ruby useflag in IUSE of app-text/docbook-xsl-stylesheets to > epub because it doesn't add ruby support but enable or not the installation > of a ruby script used to do the conversion to epub format I strongly agree with this. > * add an epub useflag also to app-text/asciidoc to be able to propagate the > correct useflag also to its dependency app-text/docbook-xsl-stylesheets, in > this way the above mentioned hack is not needed I don't agree with this. Adding USE flags solely for dependencies is not a good idea (at least with current portage, e.g., a USE flag change would cause a rebuild of asciidoc without anything changing on-disc), and is thus also a QA violation. I could ask for an exception, but I don't think it's necessary in this case. > I am not an expert of xsltproc at all so maybe there is a better explanation > of what happens and then another solution. What do you think? I'm not an expert either. Regardless, I think your package should just depend on app-text/docbook-xsl-stylesheets[ruby] itself (maybe behind the "doc" USE flag, depending on the type of documentation), since it can be viewed as a dependency of your package, too. But to be on the safe side, you could of course ask for a developer's opinion on IRC; if you're a proxied maintainer, ask on one of the various proxy-maint communication channels. (Because really, bugzilla is not particularly suited for this type of discussion.)
No reaction in almost 1.5 years, closing ("INVALID" because I don't see a bug here). Feel free to reopen if you still see a need to discuss this.
