Description of problem: Whenever I run 'jhbuild sysdeps --install', the Links browser gets installed. That's not OK, development packages should not depend on unrelated GUI apps. Version-Release number of selected component (if applicable): docbook-utils-0.6.14-39 How reproducible: Always Steps to Reproduce: 1. 'sudo dnf install gtk-doc' Actual results: dnf wants to install links Expected results: dnf does not want to install links Additional info: The problem must be: Requires: text-www-browser in docbook-utils.spec. Each time Links comes back, I just remove it again with GNOME Software. Running pkmon in the background, I can see it's removing docbook-utils and gtk-doc when it does so. Such critical system components need to not depend on Links.
P.S. We have a "rule" that packages must not depend on GUI apps unless they are plugins for that app... it's not an official packaging guideline yet, but I want to make that happen.
text-www-browser requirement is needed there. It is not weird - it is used for docbook2txt - any text-www-browser satisfies the dependency. I tend to say this is notabug, although partial solution would be to move the docbook2txt plugin in the separate subpackage and reduce the dependencies for the main one. However, this may result in the broken builds - for this I need to check how many packages actually use the docbook2txt for building their docs.
Splitting the docbook2txt plugin into a subpackage would mitigate this issue, so I won't argue against that, but it's not really the correct solution as that just moves the bug into a less-essential package. To be clear, the Fedora Workstation folks consider it a bug for non-plugin packages to depend on anything that installs a user-visible desktop file. We don't actually care if it pulls in a terminal web browser -- that's totally fine -- we just don't want it showing up in the overview. An alternative solution would be to change links to not provide text-www-browser (if some other package provides that). I think the best solution would be to separate links's desktop file into a subpackage. I really should have suggested that in comment #0.
elinks, lynx and w3m provide text-www-browser ... adding Lubo Rintel to cc - Lubo, what do you think? Would you mind to do the changes on links side? Split of the docbook-utils package is doable, but it will require investigation of the build dependencies in Fedora - as some builds may depend on docbook2txt .
Hey Lubomir, have you had a chance to look at this? Splitting the desktop file out would be the best solution; alternatively you could add NotShowIn=GNOME; to it.
I'd prefer to remove the text-www-browser Provide from links when the problem is that it is, in fact, a graphical browser. I doubt anyone would miss it. Would that work for you?
(In reply to Lubomir Rintel from comment #6) > I'd prefer to remove the text-www-browser Provide from links when the > problem is that it is, in fact, a graphical browser. I doubt anyone would > miss it. > > Would that work for you? Yeah that seems best... I guess I never launched Links before today, I didn't realize it had a GUI.
(In reply to Lubomir Rintel from comment #6) > I'd prefer to remove the text-www-browser Provide from links when the > problem is that it is, in fact, a graphical browser. I doubt anyone would > miss it. > > Would that work for you? Hey Lubomir, can you or a provenpackager make this happen, please?
The other option here of course is for us to add `Suggests: elinks` to the docbook-utils package. The result will be that if no text-www-browser Provides is already on the system, DNF will choose elinks to satisfy it, rather than following its normal algorithm for picking one. I don't think removing text-www-browser from Links necessarily makes sense, because it *does* provide a text-only browser as well. Ideally, that package would be split into "links" and "links-gui", but I think that's a different bug than this one here.
(In reply to Stephen Gallagher from comment #9) > The other option here of course is for us to add `Suggests: elinks` to the > docbook-utils package. The result will be that if no text-www-browser > Provides is already on the system, DNF will choose elinks to satisfy it, > rather than following its normal algorithm for picking one. Let's try this. Though: I wonder if PackageKit is as smart as dnf here.
(In reply to Michael Catanzaro from comment #10) > (In reply to Stephen Gallagher from comment #9) > > The other option here of course is for us to add `Suggests: elinks` to the > > docbook-utils package. The result will be that if no text-www-browser > > Provides is already on the system, DNF will choose elinks to satisfy it, > > rather than following its normal algorithm for picking one. > > Let's try this. > > Though: I wonder if PackageKit is as smart as dnf here. It should be; if I recall correctly, this feature is provided by the underlying libsolv library which both of them use.
I'm happy to help fix this up on the PackageKit side if it doesn't work, if someone could test this please.
Hey Stephen, got time to look into this again? Adding a Suggest: elinks to the docbook-utils package seems like a fine idea.
(In reply to Michael Catanzaro from comment #13) > Hey Stephen, got time to look into this again? > > Adding a Suggest: elinks to the docbook-utils package seems like a fine idea. I'm not sure what you need from me. I was advising a course of action, but I'm not a maintainer of docbook-utils.
Let's move this back to docbook-utils then. links is free to use a desktop file if it really wants to, but docbook-utils is not free to depend on a package that installs a visible desktop file. (In reply to Stephen Gallagher from comment #14) > I'm not sure what you need from me. I was advising a course of action, but > I'm not a maintainer of docbook-utils. You might recall you got involved here when I asked for a provenpackager to help, as I was getting frustrated at how long it's been open and the highly-visible nature of this bug. That was months ago now. :( Hopefully this can be resolved soon.
(In reply to Michael Catanzaro from comment #15) > You might recall you got involved here when I asked for a provenpackager to > help, as I was getting frustrated at how long it's been open and the > highly-visible nature of this bug. That was months ago now. :( Hopefully > this can be resolved soon. Ah, I had forgotten that. Yes, I'd be happy to apply that patch to docbook-utils for you. Sorry for the confusion.
(In reply to Michael Catanzaro from comment #15) > Let's move this back to docbook-utils then. links is free to use a desktop > file if it really wants to, but docbook-utils is not free to depend on a > package that installs a visible desktop file. The dependency on text-www-browser is there for a reason. See bug #174566.
(In reply to Kamil Dudka from comment #17) > (In reply to Michael Catanzaro from comment #15) > > Let's move this back to docbook-utils then. links is free to use a desktop > > file if it really wants to, but docbook-utils is not free to depend on a > > package that installs a visible desktop file. > > The dependency on text-www-browser is there for a reason. See bug #174566. Right, there's no problem with that. However, what is being asked for is this: in the case where this is not already satisfied, we should be pulling in a preferred one like elinks rather than links which is both a text and GUI provider (and thus causes X11 to be pulled in). I'm going to modify the docbook-utils package to include `Suggests: elinks` which means that it will prefer elinks if no other text-www-browser is already on the system or part of the same transaction.
docbook-utils-0.6.14-41.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-969a11b8f3
docbook-utils-0.6.14-41.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-969a11b8f3
Thanks Stephen, I missed the comment about the Suggest (400+ emails from BZ every day - so I check just needinfos and things where I'm assigned to). Reassign would be sufficient here... I think this solution is good idea even for other docbook-related tools that use text-www-browser requires - e.g. xmlto - as other packages may require this package to build documentation from docbook - and can bring in links same way.
Hmmms, I fixed that in xmlto different way already... nevermind...
docbook-utils-0.6.14-41.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.