app-text/asciidoc depends on media-gfx/graphviz which brings in a whole host of imaging and font libraries which are unnecessary and useless on an X-less server type installation. I've removed the dependency locally and asciidoc builds without issue and seems to working normally for applications that use it for man pages (sys-apps/paludis) Is there any way that the media-gfx/graphviz dependency could be controlled by a USE flag? Thanks Reproducible: Always
This is important for reducing the number of dependencies for dev-util/catalyst now that it uses asciidoc to generate its man page.
Actually the dependency should not even be optional, it is simply completely incorrect and should just be removed. asciidoc does not in any way depend on graphviz to function correctly. The only connection is that one of the filters included with asciidoc can be used to call graphviz. Another such filter can be used to call LilyPond and ImageMagick, but neither are those packages dependencies for asciidoc nor should they be. Will attach patch for live ebuild and new -r ebuild for last version in portage.
Created attachment 278297 [details, diff] Remove bogus media-gfx/graphviz RDEPEND from asciidoc-9999
Created attachment 278299 [details] Update asciidoc-8.5.3 to not depend on media-gfx/graphviz
Created attachment 278301 [details] Update asciidoc-8.6.3 to not depend on media-gfx/graphviz
Created attachment 278303 [details] Update asciidoc-8.6.4 to not depend on media-gfx/graphviz
Created attachment 278305 [details] Update asciidoc-8.6.5 to not depend on media-gfx/graphviz
Created attachment 278307 [details, diff] Remove bogus media-gfx/graphviz RDEPEND from asciidoc-9999 ..but leave it in as dependency with USE=test
Created attachment 278309 [details] Update asciidoc-8.6.4 to not depend on media-gfx/graphviz Updated to keep the graphviz dep with USE=text
Created attachment 278311 [details] Update asciidoc-8.6.5 to not depend on media-gfx/graphviz Updated to keep graphviz dep with USE=test
Created attachment 278315 [details, diff] Remove bogus media-gfx/graphviz RDEPEND from asciidoc-9999 Meh attached the complete ebuild instead of patch. Oops.
(In reply to comment #11) > Meh attached the complete ebuild instead of patch. Oops. A single patch would suffice next time, yes. Dependency now removed as requested. However, with USE=test it remains. + 27 Jun 2011; Sebastian Pipping <sping@gentoo.org> asciidoc-8.5.3.ebuild, + asciidoc-8.6.3.ebuild, asciidoc-8.6.4.ebuild, asciidoc-8.6.5.ebuild, + asciidoc-9999.ebuild: + Remove runtime dependency on graphviz (bug #361255) +
(In reply to comment #2) > Actually the dependency should not even be optional, it is simply completely > incorrect and should just be removed. > asciidoc does not in any way depend on graphviz to function correctly. The only > connection is that one of the filters included with asciidoc can be used to > call graphviz. Another such filter can be used to call LilyPond and > ImageMagick, but neither are those packages dependencies for asciidoc nor > should they be. They should be runtime dependencies controlled by use flags. So you would have something like: RDEPEND="graphviz? ( packages for graphviz ) lillypond? ( packages for lillypond ) imagemagic? ( packages for imagemagic )" Completely removing them is not the correct fix.
(In reply to comment #13) > They should be runtime dependencies controlled by use flags. I considered that option. Why should they be controlled by use flags? Is there any policy about this?
(In reply to comment #13) > (In reply to comment #2) > > Actually the dependency should not even be optional, it is simply completely > > incorrect and should just be removed. .. > Completely removing them is not the correct fix. Disagree. asciidoc itself does not change at all and really does not need those programs, so I think having USE flags for each of those dependencies would be a lie. If I am a package that uses asciidoc, and I use the asciidoc graphviz filter, then it is *I* that depend on graphviz, not asciidoc. Or? You could argue that the asciidoc filter being installed is what the USE flag would control. Personally I think that's wrong, since asciidoc itself *really* never depends on graphviz or lilypond. Only asciidoc users can cause need for graphviz, so I think that is where a USE=graphviz should go.
(In reply to comment #15) > (In reply to comment #13) > > (In reply to comment #2) > > > Actually the dependency should not even be optional, it is simply completely > > > incorrect and should just be removed. > .. > > Completely removing them is not the correct fix. > > Disagree. asciidoc itself does not change at all and really does not need those > programs, so I think having USE flags for each of those dependencies would be a > lie. > > If I am a package that uses asciidoc, and I use the asciidoc graphviz filter, > then it is *I* that depend on graphviz, not asciidoc. Or? > > You could argue that the asciidoc filter being installed is what the USE flag > would control. Personally I think that's wrong, since asciidoc itself *really* > never depends on graphviz or lilypond. Only asciidoc users can cause need for > graphviz, so I think that is where a USE=graphviz should go. There are two "schools of though" about optional run-time deps on Gentoo: 1. add the deps to packages controlling them through use flags: 2. add warnings in pkg_postinst letting users know that some features depend on installing package A, B, etc. I'm adept of the 2nd (that has been our long standing policy on KDE), but users frequently cry for the 1st and some developers also prefer it.
> (In reply to comment #16) > There are two "schools of though" about optional run-time deps on Gentoo: > > 1. add the deps to packages controlling them through use flags: > 2. add warnings in pkg_postinst letting users know that some features depend on > installing package A, B, etc. USE flags (1.) will expose possible asciidoc features during emerge --pretend while elog messages (2.) will require user to install asciidoc just to see that to make it working with graphs he/she is required to install graphviz too. For developers USE flags (1.) are better since to have asciidoc with feature graphviz he/she will have to put asciidoc[graphviz] into RDEPEND and once there arise another provider for graphs (e.g. fork of graphviz project) only dependency in asciidoc will have to be updated. Also it is possible (I'm not saying this is the case for asciidoc/graphviz, but in general such situation may happen with other packages) that to have all graphviz features in asciidoc some additional package (foo) may be or became required. So if we force packages that depend on graphviz all dependencies like: DEPEND="app-text/asciidoc media-gfx/graphviz" will have to be updated... Also in this case until some packages that depepend on asciidoc start fail to build and having new graphviz USE flag in asciidoc will expose easy fix for maintainers... 2. is better only since it keeps dependency in asciidoc easier to manage. But this may force more work on other maintainers. So... writing all of this I'm inclined to say that USE flags is better approach. In any case either 1 or 2 have to be done.
(In reply to comment #17) > > (In reply to comment #16) > > There are two "schools of though" about optional run-time deps on Gentoo: > > > > 1. add the deps to packages controlling them through use flags: > > 2. add warnings in pkg_postinst letting users know that some features depend on > > installing package A, B, etc. > > USE flags (1.) will expose possible asciidoc features during emerge --pretend > while elog messages (2.) will require user to install asciidoc just to see that > to make it working with graphs he/she is required to install graphviz too. I've seen both 1. and 2. in use. I personally expect a USE flag to only be used when what is installed by the package actually changes in some way depending on that flag. Since asciidoc does not change I don't know if a USE flag fits? > once there arise another provider for graphs (e.g. fork of graphviz project) That's maybe a little far-fetched, but at that point isn't virtual/graphviz a better solution? > Also it is possible (I'm not saying this is the case for asciidoc/graphviz, but > in general such situation may happen with other packages) that to have all > graphviz features in asciidoc some additional package (foo) may be or became > required. So if we force packages that depend on graphviz all dependencies > like: > > DEPEND="app-text/asciidoc > media-gfx/graphviz" > > will have to be updated... Is not the case, but I see the point. > Also in this case until some packages that depepend on asciidoc start fail to > build and having new graphviz USE flag in asciidoc will expose easy fix for > maintainers... I guess the real question is what is intended, desired and allowed use of USE: a. list runtime options that have no effect on the package itself b. control actual hard dependencies; build and run time c. convenience for other ebuild maintainers I expect b. to be the primary use, with a "maybe sometimes but rather not" attitude for a. and that c. is frowned upon. > 2. is better only since it keeps dependency in asciidoc easier to manage. Again, personally I don't think asciidoc can ever be said to depend on graphviz. So it's more a question of what meaning USE flags can have. :)
The oldest version of asciidoc in the tree (8.2.6) does not have the dependency on graphviz, so you can easily narrow down the number of packages that actually require asciidoc+graphviz to those that depend on something newer than asciidoc-8.2.6. /me votes for no USE flag
(In reply to comment #16) > There are two "schools of though" about optional run-time deps on Gentoo: > > 1. add the deps to packages controlling them through use flags: > 2. add warnings in pkg_postinst letting users know that some features depend on > installing package A, B, etc. Interesting. My vote for either - documenting and letting devs decide individually - documenting, making one option a policy, add question to ebuild quiz I guess the page http://devmanual.gentoo.org/general-concepts/dependencies/index.html should offer an answer to that (but doesn't seem to do). Open devmanual/QA bug for it? (In reply to comment #17) > USE flags (1.) will expose possible asciidoc features during emerge --pretend > while elog messages (2.) will require user to install asciidoc just to see that > to make it working with graphs he/she is required to install graphviz too. > > For developers USE flags (1.) are better since to have asciidoc with feature > graphviz he/she will have to put asciidoc[graphviz] into RDEPEND and once > [..] only dependenc[ies] in asciidoc will have to be updated. Thanks for that explanation. I see where you go with this. > > 2. is better only since it keeps dependency in asciidoc easier to manage. > > Again, personally I don't think asciidoc can ever be said to depend on > graphviz. [..] I start to disagree on that. The integration with graphviz is coded into asciidoc, the invocation of graphviz/dot is done by asciidoc. (In reply to comment #19) > The oldest version of asciidoc in the tree (8.2.6) does not have the dependency > on graphviz, so you can easily narrow down the number of packages that actually > require asciidoc+graphviz to those that depend on something newer than > asciidoc-8.2.6. I'm not sure what's the point with this^^^ Let me dare try an overview how current favors seem to be distributed: Definitions: (A) Add "graphviz? ( media-gfx/graphviz )" to RDEPEND (B) Add "it makes sense to have media-gfx/graphviz installed" to pkg_postinst (C) Do neither (1) or (2) Favor as perceived by sping: jmbsvicetoo: B ("I'm adept of the 2nd") stuge: B or C, not A (~"does not depend on graphviz") william: A ("[R]emoving them is not the correct fix.") matt: B or C, not A ("/me votes for no USE flag") pva: A over B, not C ("[..] 1 or 2 have to be done.) sping: A at best ("convinced by pva on A, now") Please correct me if you feel mis-represented.
(In reply to comment #20) > (In reply to comment #19) > > The oldest version of asciidoc in the tree (8.2.6) does not have the dependency > > on graphviz, so you can easily narrow down the number of packages that actually > > require asciidoc+graphviz to those that depend on something newer than > > asciidoc-8.2.6. > > I'm not sure what's the point with this^^^ My point is regarding packages that depend on app-text/asciidoc. Currently, they may actually depend on functionality of asciidoc+graphviz, but only the asciidoc dependency is listed. So, if asciidoc adds a graphviz USE flag, or we need to determine which packages are in this category, then we may narrow down the set to only those packages which depend on asciidoc newer than 8.2.6, since 8.2.6 doesn't depend on graphviz.
(In reply to comment #21) > My point is regarding packages that depend on app-text/asciidoc. Currently, > they may actually depend on functionality of asciidoc+graphviz, but only the > asciidoc dependency is listed. Alright. I doubt there are many and I think we could live with people opening bugs for the few cases where that may happen. Agreed?
(In reply to comment #22) > Alright. I doubt there are many and I think we could live with people opening > bugs for the few cases where that may happen. Agreed? Indeed, it shouldn't be a problem. From the looks of it, most packages seem to simply use asciidoc to generate their man pages, so no graphviz needed.
(In reply to comment #17) > > (In reply to comment #16) > > There are two "schools of though" about optional run-time deps on Gentoo: > > > > 1. add the deps to packages controlling them through use flags: > > 2. add warnings in pkg_postinst letting users know that some features depend on > > installing package A, B, etc. > > USE flags (1.) will expose possible asciidoc features during emerge --pretend > while elog messages (2.) will require user to install asciidoc just to see that > to make it working with graphs he/she is required to install graphviz too. There's one "misconception" here. You don't need to install graphviz and rebuild asciidoc to get the support for graphs - as your comment above seems to imply. What happens here is that asciidoc is able to take advantage of graphviz if it's installed, but works correctly without it installed. The reason why the long standing policy on KDE about optional run-time deps is to just list them in pkg_postinst is that a few packages in KDE (the worst of which iirc was quanta) had tens of optional run-time deps. > For developers USE flags (1.) are better since to have asciidoc with feature > graphviz he/she will have to put asciidoc[graphviz] into RDEPEND and once there > arise another provider for graphs (e.g. fork of graphviz project) only > dependency in asciidoc will have to be updated. I agree with Peter that no functionality of asciidoc is affected by having graphviz around, so the above dep would seem wrong. If a package requires asciidoc and its support for graphviz, then that package should have a dep on both asciidoc and graphviz. > Also in this case until some packages that depepend on asciidoc start fail to > build and having new graphviz USE flag in asciidoc will expose easy fix for > maintainers... I would think the failure would be in the package and not asciidoc since it will produce the exact same code with or without graphviz in the system - no automagic dep here. As I've said, I prefer 2 here, but I understand and accept some people prefer 1. As I'm not the maintainer of this package, I just wanted to share my opinion. I'm fine with whatever maintainer / herd decides.
(In reply to comment #24) > There's one "misconception" here. You don't need to install graphviz and > rebuild asciidoc to get the support for graphs - as your comment above seems to > imply. Since elog is shown after package installation at time run `emerge --pretend asciidoc` you are yet unaware that to have asciidoc with graph support you'll have to install graphviz. That said I'm fine with any solution: elog or use flags.
Wow, been afk for a couple of days - seems I've opened a can of worms :) FWIW I think 2 (pkg_postinst) is the most pragmatic way to handle this situation, and it's not without precedent, I've just noticed this is exactly how dev-vcs/git does it... *** Messages log: /var/log/paludis/1309251187-install-dev-vcs_git-1.7.6:0::gentoo.messages *** These additional scripts need some dependencies: *** git-quiltimport : dev-util/quilt *** git-instaweb : || ( www-servers/lighttpd www-servers/apache ) Thanks
I have decided for "graphviz? ( media-gfx/graphviz )" now. It may help some people and without USE=graphiz it will not push anything on you either. I hope everyone can live with that. + 30 Jun 2011; Sebastian Pipping <sping@gentoo.org> asciidoc-8.5.3.ebuild, + asciidoc-8.6.3.ebuild, asciidoc-8.6.4.ebuild, asciidoc-8.6.5.ebuild, + asciidoc-9999.ebuild: + Add "graphviz? ( media-gfx/graphviz )" to runtime dependencies (bug #361255) +
