As by upstream's rationale [1], it shouldn't be necessary to depend on Java. I'm not sure whether that's compatible with Gentoo's policies but I'd like to propose that something be done about it one way or another, because pulling in Java for just one of the dozens of backends sounds like a recipe for extreme bloat. Can the dependency be skipped, since upstream distributes JARs? Do we have to patch or split out the gems into individual packages? [1] https://github.com/asciidoctor/asciidoctor-diagram/issues/376#issuecomment-1712744232
If you want to run any of the bundled java diagram tools you'll need to have a java interpreter. I guess we could move this dependency behind a USE flag, either with a USE flag for each diagram tool (I count 5 at the moment) or a generic "java" one (but that will be a bit obscure).
If that's okay policy-wise, I'd think USE flags would be perfect. That would allow to pull in other backend binaries as needed, as I don't see a clear demarcation between Java being required for the bundled UML JAR and, say, graphviz for the graphviz backend. What do you take as a reference for counting the backends? The contents of lib/ [1] seem to suggest a plethora of backends. Do you require any help crafting the ebuild for the USE flags or is that quickly done? [1] https://github.com/asciidoctor/asciidoctor-diagram/tree/master/lib/asciidoctor-diagram
(In reply to Cedric Sodhi from comment #2) > If that's okay policy-wise, I'd think USE flags would be perfect. That would > allow to pull in other backend binaries as needed, as I don't see a clear > demarcation between Java being required for the bundled UML JAR and, say, > graphviz for the graphviz backend. Ah, right, this problem is a bit wider than just the Java extensions. For the tests we just require everything but for runtime we could use USE flags for these too. > What do you take as a reference for counting the backends? The contents of > lib/ [1] seem to suggest a plethora of backends. A lot of the backends require tools that must be installed separately. You can check the ebuild to see which specs (and thus, tools) we don't have packaged. We can skip those altogether. > Do you require any help crafting the ebuild for the USE flags or is that > quickly done? Feel free to create an initial list of IUSE and RDEPEND, I have plenty of other issues to work on so having a start here would be useful. Bonus points for adding the metadata USE flag descriptions :-)
I went through all backends documented by asciidoctor-diamgram [1] and found that the following are packaged in Gentoo, while all others are not: > Barcode ( dev-ruby/rqrcode dev-ruby/barby ) > Ditaa ( media-gfx/ditaa virtual/jre ) > Gnuplot ( sci-visualization/gnuplot ) > Graphviz ( media-gfx/graphviz ) > Lilypond ( media-sound/lilypond ) > Meme ( media-gfx/imagemagick[png] ) > MscGen ( media-gfx/mscgen[png] ) > PlantUML ( media-gfx/plantuml virtual/jre ) I will write those into USE flags with the according name.
[1] https://docs.asciidoctor.org/diagram-extension/latest/ > Diagram Types
I forgot > TikZ ( dev-tex/pgf ) Do we need an explicit texlive dependency?
Created attachment 870274 [details, diff] Added USE flags
Created attachment 870276 [details, diff] USE flags and cleanup (I'm not sure whether that's not completely idiotic or otherwise unacceptable for an ebuild) I haven't managed to fully clean up the installed image - only the spec and the lib/-files are deleted. There are JAR files in there of which I don't know at all where they are coming from (they are not in the source tree).
Created attachment 870277 [details, diff] USE flags and cleanup
It's not good yet. Deleting the ruby files messes up the requires from asciidoctor.rb and salt.rb.
Created attachment 870278 [details, diff] Corrected version of ebuild patch This works now as far as I tested it. I filed an inquiry [1] upstream which could perhaps get rid of the special handle of the "salt.rb" file, if they humor it. [1] https://github.com/asciidoctor/asciidoctor-diagram/issues/434
Any feedback whether this is okay(-ish) or not?
bash hashes/dicts :-) It looks fine in general. Two minor issues: 1) RDEPEND and DEPEND must be added to. Perhaps we should create locals in the loop and add the result to RDEPEND/DEPEND. That would make things a bit more clear I think. 2) You are assuming that all *_spec.rb files are for diagram dependencies. This may be true now (I haven't checked) but may not be true in the future and then we would throw away more generic specs without knowing. Also, with new versions new diagram tools would be thrown out silently. A fixed list would be more explicit here. I'll have a more detailed look later this weekend.
I don't understand what you mean in "1)". They are being added to (by the += as you certainly saw), what is missing? Regarding 2), > Also, with new versions new diagram tools would be thrown out silently. That was actually my primary design goal in it! Short of semantic changes (such as *.spec files no longer mapping 1-to-1 onto the types of diagrams) - which will require an update to how the script works anyway - the script can be applied to all future versions and will not pass new diagram-types into Gentoo without our explicit confirmation. Two reasons why I think this is good: a. The maintainer is not required to review, configure or disable newly added diagram types as Upstream adds them, but will get the benefit of updates for the diagram-types which are supported. b. If new diagram-types were to "pop up" from an update without maintainer intervention, that would be contrary and no longer analogous to the behaviour of portage if diagram-types were published in separate ebuilds each: There, too, a new diagram would be added only through maintainer intervention.
NVM 1), I understand now that ?DEPEND must only be added to anywhere in the ebuild!
Created attachment 870812 [details, diff] Ebuild patch Corrected for version 2.2.12
I just added asciidoctor-diagram 2.2.14 and also applied to changes in the patch to it. Apologies for the delay.
