Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 366763

Summary: app-text/asciidoc-8.6.4 should RDEPEND on app-text/dblatex || ( www-client/w3m www-client/lynx )
Product: Gentoo Linux Reporter: Thomas Capricelli <orzel>
Component: Current packagesAssignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>
Status: CONFIRMED ---    
Severity: normal CC: 1i5t5.duncan, djc, ifaigios, jrmalaq, jstein, kripton, marcec, mgorny, nrk, pageexec, proxy-maint, sam, sokann, tom_gentoo, zoltan
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 424283, 129368    
Bug Blocks: 388225, 468356, 577838    

Description Thomas Capricelli 2011-05-10 14:23:53 UTC
When creating a pdf file using asciidoc, the executable a2x(.py) calls another one 'dblatex', which is not present. As such, the asciidoc package is broken.

There is an ebuild request for dblatex (http://bugs.gentoo.org/show_bug.cgi?id=129368), but it seems the ebuild is broken and not maintained anymore.

Reproducible: Always
Comment 1 Ian Delaney (RETIRED) gentoo-dev 2012-03-24 11:24:18 UTC
2006; my my.  Does this warrant re-making an ebuild dblatex?
Comment 2 Mike Gilbert gentoo-dev 2012-03-25 20:53:10 UTC
What's the use case for this? The docs say you should be using RELAX NG.
Comment 3 Mike Gilbert gentoo-dev 2012-03-25 20:53:34 UTC
(In reply to comment #2)
> What's the use case for this? The docs say you should be using RELAX NG.

Wrong bug, sorry.
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2013-07-11 14:02:38 UTC
Additionally, /usr/bin/a2x appears to want either www-client/w3m or www-client/lynx.
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2015-01-20 18:34:45 UTC
How are we doing here?
Comment 6 Zoltan Puskas 2015-11-09 01:57:28 UTC
We have dblatex-0.3.7 in the portage tree now. See if it works for you.
Comment 7 Marc Joliet 2015-11-09 14:30:51 UTC
See also https://github.com/gentoo/gentoo/pull/344.
Comment 8 Thomas Arnett 2015-11-14 20:46:12 UTC
A number of packages unconditionally depend on app-text/asciidoc, including:
dev-util/catalyst
sys-fs/btrfs-progs
sys-kernel/dracut
sys-kernel/genkernel-next

Should installing btrfs-progs pull in the entire XeTeX stack?

Also, AsciiDoc can be configured to use other programs in place of Lynx or W3M. The documentation mentions Links and Elinks; it seems like html2text would also work.
Comment 9 Holger Hoffstätte 2015-11-15 08:00:33 UTC
(In reply to Thomas Arnett from comment #8)
> Should installing btrfs-progs pull in the entire XeTeX stack?

No, of course not. I'd expect a pdf useflag on asciidoc instead.
Comment 10 Marc Joliet 2015-11-15 09:39:30 UTC
First off, the abovementioned PR has been merged.

(In reply to Holger Hoffstätte from comment #9)
> (In reply to Thomas Arnett from comment #8)
> > Should installing btrfs-progs pull in the entire XeTeX stack?
> 
> No, of course not. I'd expect a pdf useflag on asciidoc instead.

I still have documentation to read, but here are my current thoughts:

Putting the deps behind a USE flag would be a QA violation, because they're runtime deps.  Asciidoc already does this with the highlight USE flag, but that doesn't mean more should be added.  mgorny pointed me to https://wiki.gentoo.org/wiki/GLEP:62 in a similar case, which looks like it would solve these annoying runtime dependency problems.  Perhaps it can be pushed for EAPI 7?

Until then, I'm not sure what the best course of action is.  Drop all but the actually required dependencies and use README.gentoo, or leave things as they are for now, or something else entirely (e.g., maybe use asciidoctor where possible)?
Comment 11 Holger Hoffstätte 2015-11-15 14:16:04 UTC
(In reply to Marc Joliet from comment #10)

While the root of the problem is clearly the monolithic design of a2x,
maybe a temporary workaround would be a "minimal" use flag so that
we can use it for man pages only (which probably does not require
graphviz either). Then just skip installing a2x to avoid the broken
runtime dependency for system packages.
Comment 12 wjn 2015-11-15 18:39:21 UTC
 I think there should be more USE flags in the ebuild files.
I want much better ${RDEPEND}.

 runtime dependencies are showed in a2x.1 (man 1 a2x).
http://code.google.com/p/asciidoc/source/browse/doc/a2x.1.txt#274

- dblatex is not always depended (depended for pdf, dvi, ps, tex formats).
  And fop is an alternative for pdf format (instead of dblatex).

- If text generation is not needed, w3m and lynx is not depended.
  On the other hand, libxslt and docbook-xsl-stylesheet are always depended except for text generation.

- epubcheck is depended for epub format.
Comment 13 Duncan 2015-11-16 07:47:01 UTC
(In reply to Marc Joliet from comment #10)
> First off, the abovementioned PR has been merged.
> 
> (In reply to Holger Hoffstätte from comment #9)
> > (In reply to Thomas Arnett from comment #8)
> > > Should installing btrfs-progs pull in the entire XeTeX stack?
> > 
> > No, of course not. I'd expect a pdf useflag on asciidoc instead.
> 
> I still have documentation to read, but here are my current thoughts:
> 
> Putting the deps behind a USE flag would be a QA violation, because they're
> runtime deps.

[After metaphorically sticking my head in ice for a few minutes to calm the steam shooting out my ears! Posting while mad helps no one. =:^( ]

Pulling in dblatex, along with its brother and sister and 3 aunts and 5 cousins and a dozen second cousins and 20 third-cousins, including the texlive subsystem, as a _mandatory_ dep that's actually optional and unnecessary for many/most of the rev-deps that pull it in, is...

let's just say... "suboptimal", to put it mildly.

I've not decided whether I'm going to deal with this one for the moment by package.providing dblatex, or masking the new revision, but I didn't need those deps on my system to generate btrfs or dracut manpages before, and I don't need them on my system now.  Please kill that mandatory dep that _should_ be optional, however you decide to do it.


Meanwhile, FWIW, such runtime-only optional deps have traditionally been dealt with using a pkg_postinst() message saying something to the effect of "If you want to use asciidoc to generate PDFs, please install app-text/dblatex."

These days, there's even a helper function, optfeature, from the eutils eclass, to help (semi-)standardize these messages.  See for example the usage in the pkg_postinst() of sys-boot/grub:2 and/or sys-kernel/dracut, for how optfeature is setup and how it can be used for multiple features, each provided by their own runtime-optional package(s).

Another alternative is using readme.gentoo.eclass.  From a quick grep of the tree, this solution appears to be very widely used, altho not always for runtime-optional package notifications.  Three of the popular packages using it are dev-util/ccache, media-libs/fontconfig, and x11-libs/gtk+:2.

Thanks. =:^)
Comment 14 Marc Joliet 2015-11-16 08:49:37 UTC
(In reply to Duncan from comment #13)
[...]
> These days, there's even a helper function, optfeature, from the eutils
> eclass, to help (semi-)standardize these messages.  See for example the
> usage in the pkg_postinst() of sys-boot/grub:2 and/or sys-kernel/dracut, for
> how optfeature is setup and how it can be used for multiple features, each
> provided by their own runtime-optional package(s).

Ah, I didn't know of optfeature!  That sounds pretty useful.

> Another alternative is using readme.gentoo.eclass.  From a quick grep of the
> tree, this solution appears to be very widely used, altho not always for
> runtime-optional package notifications.  Three of the popular packages using
> it are dev-util/ccache, media-libs/fontconfig, and x11-libs/gtk+:2.
> 
> Thanks. =:^)

I mentioned that after the stuff you quoted, FYI.

Anyway, starting now, please direct further discussion to bug #565844.  I'd prefer for *this* bug to stay open until a proper way of tracking optional runtime dependencies emerges.
Comment 15 Marc Joliet 2015-11-16 10:58:00 UTC
(In reply to Holger Hoffstätte from comment #11)
> (In reply to Marc Joliet from comment #10)
> 
> While the root of the problem is clearly the monolithic design of a2x,
> maybe a temporary workaround would be a "minimal" use flag so that
> we can use it for man pages only (which probably does not require
> graphviz either). Then just skip installing a2x to avoid the broken
> runtime dependency for system packages.

Just to document this: I asked about that in the pull request (though I wouldn't use "minimal" for that), but never got a response.  Personally, I don't like it, because the asciidoc build system doesn't handle a2x and asciidoc separately, so you have to manually delete it (and its man-page) before merging, and that just seems wrong to me.  Patching the build system also doesn't look straightforward to me.

Personally, I agree with Mika K., but that would require the aforementioned GLEP 62.
Comment 16 Marc Joliet 2015-11-16 13:50:24 UTC
(In reply to Marc Joliet from comment #15)
[...]
> Just to document this: I asked about that in the pull request
[...]

And to prevent confusion: I meant in the original pull request at https://github.com/gentoo/gentoo/pull/291.
Comment 17 Jonas Stein gentoo-dev 2017-11-11 17:44:39 UTC
The PR was merged long ago. Can we close this as fixed, or is something left to do?
Comment 18 Duncan 2017-11-11 18:38:29 UTC
(In reply to Jonas Stein from comment #17)
> The PR was merged long ago. Can we close this as fixed, or is something left
> to do?

See comment#14:  "I'd prefer for *this* bug to stay open until a proper way of tracking optional runtime dependencies emerges."

I don't believe that to have happened, tho arguably with the rdep taken care of now via the readme.gentoo-r1 eclass, the bug is no longer with ascidoc, but rather a wishlist/enhancement-level future-EAPI bug, and could either be retitled/reassigned as such, or perhaps better, made a dep of some optional-rdeps future-EAPI tracker bug.
Comment 19 Jeroen Roovers (RETIRED) gentoo-dev 2017-12-01 15:02:43 UTC
(In reply to Jonas Stein from comment #17)
> The PR was merged long ago. Can we close this as fixed, or is something left
> to do?

asciidoc-9999.ebuild has a DEPEND (but not RDEPEND!) on www-client/lynx. No other ebuild has this. www-client/w3m is mentioned nowhere.
Comment 20 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-08-03 08:29:24 UTC
Ping.  Marc, can you look at this, please?
Comment 21 Marc Joliet 2019-08-04 21:10:09 UTC
(In reply to Michał Górny from comment #20)
> Ping.  Marc, can you look at this, please?
At this point, if you think there is no future for GLEP 62, then I can close this as CANTFIX, otherwise I'd prefer to keep it open.  Would that be fine with you?

Either way, I'm adding a dependency on bug #424283 for completeness.