Hi,
Not all of the packages that use Yelp actually depend on it and the current package list seems completely arbitrary.
$ repoquery --alldeps --whatrequires yelp
system-config-samba-docs-0:1.0.8-1.fc13.noarch gnochm-0:0.9.11-5.fc13.noarch xiphos-0:3.1.3-1.fc13.i686 deja-dup-0:14.1-1.fc13.i686 system-config-nfs-docs-0:1.0.8-1.fc13.noarch system-config-users-docs-0:1.0.8-1.fc13.noarch lat-0:1.2.3-10.fc13.i686 conglomerate-0:0.9.1-7.fc12.i686 system-config-date-docs-0:1.0.9-1.fc13.noarch system-config-services-docs-0:1.1.8-1.fc13.noarch simple-scan-0:1.0.2-1.fc13.i686 moserial-0:2.28.0-2.fc13.i686 system-config-kdump-0:2.0.3-2.fc13.noarch gnucash-docs-0:2.2.0-4.fc12.noarch f-spot-0:0.6.1.5-2.fc13.i686
---
What is the recommended method? Two of the packages - deja-dup and simple-scan are mine and I have gotten a bug report to drop the Yelp dependency on deja-dup.
Rahul
2010/5/17 Rahul Sundaram metherid@gmail.com
Hi,
Not all of the packages that use Yelp actually depend on it and the current package list seems completely arbitrary.
$ repoquery --alldeps --whatrequires yelp
system-config-samba-docs-0:1.0.8-1.fc13.noarch gnochm-0:0.9.11-5.fc13.noarch xiphos-0:3.1.3-1.fc13.i686 deja-dup-0:14.1-1.fc13.i686 system-config-nfs-docs-0:1.0.8-1.fc13.noarch system-config-users-docs-0:1.0.8-1.fc13.noarch lat-0:1.2.3-10.fc13.i686 conglomerate-0:0.9.1-7.fc12.i686 system-config-date-docs-0:1.0.9-1.fc13.noarch system-config-services-docs-0:1.1.8-1.fc13.noarch simple-scan-0:1.0.2-1.fc13.i686 moserial-0:2.28.0-2.fc13.i686 system-config-kdump-0:2.0.3-2.fc13.noarch gnucash-docs-0:2.2.0-4.fc12.noarch f-spot-0:0.6.1.5-2.fc13.i686
What is the recommended method? Two of the packages - deja-dup and simple-scan are mine and I have gotten a bug report to drop the Yelp dependency on deja-dup.
Rahul
I think it's the same case as man page, packages which contain man pages don't depend on man or man-db. So the answer is probably not. I think we need a gnome-filesystem package as kde-filesystem or mozilla-filesystem to own some common directories in gnome desktop.
Chen Lei
On 05/17/2010 06:49 AM, Chen Lei wrote:
What is the recommended method? Two of the packages - deja-dup and simple-scan are mine and I have gotten a bug report to drop the Yelp dependency on deja-dup. Rahul
I think it's the same case as man page, packages which contain man pages don't depend on man or man-db. So the answer is probably not. I think we need a gnome-filesystem package as kde-filesystem or mozilla-filesystem to own some common directories in gnome desktop.
Any other recommendations? Otherwise I am dropping yelp dependencies in rawhide.
Rahul
On Thu, May 20, 2010 at 10:56:07PM +0530, Rahul Sundaram wrote:
Any other recommendations? Otherwise I am dropping yelp dependencies in rawhide.
I added a dependency on yelp in gnochm because I thought that having a click on the help button leading to a window with an error message is not acceptable for a graphical interface.
Very different from man pages in my opinion.
On 05/21/2010 01:38 AM, Patrice Dumas wrote:
On Thu, May 20, 2010 at 10:56:07PM +0530, Rahul Sundaram wrote:
Any other recommendations? Otherwise I am dropping yelp dependencies in rawhide.
I added a dependency on yelp in gnochm because I thought that having a click on the help button leading to a window with an error message is not acceptable for a graphical interface.
Very different from man pages in my opinion.
Precisely the reason why I added that dependency but we should have consistent packaging. At this point, some packages depend on yelp while others don't and it is arbitrary.
Rahul
2010/5/21 Patrice Dumas pertusus@free.fr
On Thu, May 20, 2010 at 10:56:07PM +0530, Rahul Sundaram wrote:
Any other recommendations? Otherwise I am dropping yelp dependencies in rawhide.
I added a dependency on yelp in gnochm because I thought that having a click on the help button leading to a window with an error message is not acceptable for a graphical interface.
Very different from man pages in my opinion.
It's a case by case issue, many packages contain yelp files don't have a help button, so remove yelp dependency won't break anything.
Chen Lei
On 05/21/2010 07:05 AM, Chen Lei wrote:
2010/5/21 Patrice Dumas <pertusus@free.fr mailto:pertusus@free.fr>
On Thu, May 20, 2010 at 10:56:07PM +0530, Rahul Sundaram wrote: > > Any other recommendations? Otherwise I am dropping yelp dependencies in > rawhide. I added a dependency on yelp in gnochm because I thought that having a click on the help button leading to a window with an error message is not acceptable for a graphical interface. Very different from man pages in my opinion.
It's a case by case issue, many packages contain yelp files don't have a help button, so remove yelp dependency won't break anything.
That sounds like a bug. Which applications are that way?
Rahul
On Fri, May 21, 2010 at 07:08:20AM +0530, Rahul Sundaram wrote:
That sounds like a bug. Which applications are that way?
I may not be the most qualified to answer that, but it seems to me that the manuals are more or less docbook manuals, omf files are just metadata for the manuals. So there may be some manuals distributed that way that are not associated with a button in an interface. In that case the -doc package may be optional, and there should be no yelp dependency. I recall that it was the case for gnash for some time. At least some of the manuals weren't associated with the user interface.
Patrice Dumas wrote:
I may not be the most qualified to answer that, but it seems to me that the manuals are more or less docbook manuals, omf files are just metadata for the manuals. So there may be some manuals distributed that way that are not associated with a button in an interface. In that case the -doc package may be optional, and there should be no yelp dependency. I recall that it was the case for gnash for some time. At least some of the manuals weren't associated with the user interface.
FYI, the Gnash manual doesn't build at all at the moment and hasn't for a while. You disabled it at some point, I tried reenabling it, it still failed, so it's still disabled. And the UI has never offered it.
Kevin Kofler
On Thu, 2010-05-20 at 22:56 +0530, Rahul Sundaram wrote:
On 05/17/2010 06:49 AM, Chen Lei wrote:
What is the recommended method? Two of the packages - deja-dup and simple-scan are mine and I have gotten a bug report to drop the Yelp dependency on deja-dup. Rahul
I think it's the same case as man page, packages which contain man pages don't depend on man or man-db. So the answer is probably not. I think we need a gnome-filesystem package as kde-filesystem or mozilla-filesystem to own some common directories in gnome desktop.
Any other recommendations? Otherwise I am dropping yelp dependencies in rawhide.
Just stick by it. The next version of yelp will use webkit.
Cheers
On Fri, 2010-05-21 at 02:42 +0200, Kevin Kofler wrote:
Bastien Nocera wrote:
Just stick by it. The next version of yelp will use webkit.
But webkitgtk is still an extraneous dependency of significant size on the KDE spin.
The question is why do you ship GTK+ apps on the KDE spin then, not how to cripple GTK+ apps's help.
Bastien Nocera wrote:
The question is why do you ship GTK+ apps on the KDE spin then, not how to cripple GTK+ apps's help.
Because we want our spin to be installable? The liveinst executable is part of the anaconda package, which requires a lot of GTK+-based stuff, even metacity (something I and other non-GNOME spin maintainers have been complaining about, so far to no avail). Several of the system-config-* tools dragged in by Anaconda use Yelp for documentation.
Kevin Kofler
Dne 21.5.2010 11:30, Kevin Kofler napsal(a):
Bastien Nocera wrote:
The question is why do you ship GTK+ apps on the KDE spin then, not how to cripple GTK+ apps's help.
Because we want our spin to be installable? The liveinst executable is part of the anaconda package, which requires a lot of GTK+-based stuff, even metacity (something I and other non-GNOME spin maintainers have been complaining about, so far to no avail). Several of the system-config-* tools dragged in by Anaconda use Yelp for documentation.
OK, but isn't then the solution to fix anaconda or whatever else drags in non-sensical dependencies, not yelp?
Matěj
Rahul Sundaram wrote:
Not all of the packages that use Yelp actually depend on it and the current package list seems completely arbitrary.
The reason dependencies on yelp are considered harmful is that they were dragging yelp, and with it the entire xulrunner stack, onto non-GNOME spins (which also aren't shipping Firefox, so xulrunner is a huge bloat). It was impossible to fit the KDE spin on a CD with yelp and xulrunner on it.
Looking at your list:
$ repoquery --alldeps --whatrequires yelp
system-config-samba-docs-0:1.0.8-1.fc13.noarch gnochm-0:0.9.11-5.fc13.noarch xiphos-0:3.1.3-1.fc13.i686 deja-dup-0:14.1-1.fc13.i686 system-config-nfs-docs-0:1.0.8-1.fc13.noarch system-config-users-docs-0:1.0.8-1.fc13.noarch lat-0:1.2.3-10.fc13.i686 conglomerate-0:0.9.1-7.fc12.i686 system-config-date-docs-0:1.0.9-1.fc13.noarch system-config-services-docs-0:1.1.8-1.fc13.noarch simple-scan-0:1.0.2-1.fc13.i686 moserial-0:2.28.0-2.fc13.i686 system-config-kdump-0:2.0.3-2.fc13.noarch gnucash-docs-0:2.2.0-4.fc12.noarch f-spot-0:0.6.1.5-2.fc13.i686
many of those packages which do require yelp are optional -docs subpackages, possibly for this very reason. I know for sure that we have filed release blocker bugs to get yelp dependencies dropped from stuff on the KDE spin at some point (release blocking because they made the KDE spin spill over CD size) and that this is the reason why things do not have that dependency.
What is the recommended method? Two of the packages - deja-dup and simple-scan are mine and I have gotten a bug report to drop the Yelp dependency on deja-dup.
People are asking you to drop the dependency for a reason. Please do it. Let's fight dependency bloat!
Kevin Kofler
On 05/21/2010 03:34 AM, Kevin Kofler wrote:
People are asking you to drop the dependency for a reason. Please do it. Let's fight dependency bloat!
Blindly dropping dependencies and breaking the help menu items is not a way to fight so called dependency bloat. Anyway as you are already aware, I have filed a ticket with FESCo
https://fedorahosted.org/fesco/ticket/381
Instead of restating your arguments in multiple places, we will just refer to the ticket.
Rahul
We discussed this issue at the fesco meeting today. The net outcome was that it's currently impractical to require that all packages that use yelp depend on it. However, requiring all yelp-using apps to integrate support for telling the user what's wrong may be unreasonable.
Long-term, it would be nice for this to integrate with PackageKit somehow. Short-term, the simplest solution would seem to be to provide a stub package that provides: yelp and a yelp binary, and then have that binary do nothing other than tell the user that they need to install yelp. Spins would then be at liberty to choose whether to provide the "real" yelp or the stub version. Once that's implemented dependencies can be added.
Does anyone have any objection to this approach?
On Tue, 2010-05-25 at 20:22 +0100, Matthew Garrett wrote:
We discussed this issue at the fesco meeting today. The net outcome was that it's currently impractical to require that all packages that use yelp depend on it. However, requiring all yelp-using apps to integrate support for telling the user what's wrong may be unreasonable.
Long-term, it would be nice for this to integrate with PackageKit somehow. Short-term, the simplest solution would seem to be to provide a stub package that provides: yelp and a yelp binary, and then have that binary do nothing other than tell the user that they need to install yelp. Spins would then be at liberty to choose whether to provide the "real" yelp or the stub version. Once that's implemented dependencies can be added.
Does anyone have any objection to this approach?
We would have to ensure that (1) "yum install yelp" chooses the real package rather than the stub and (2) the real package can be installed on a system containing the stub without causing a file conflict.
An alternative would be to provide a wrapper script that runs yelp if present or otherwise tells the user to install it, and have applications require the wrapper package. We could either give the wrapper script a different name and patch all applications to run that name or rename the real yelp executable and have all callers go through the wrapper. I don't see any way to avoid patching all the application packages to require the wrapper package rather than "yelp", given that we want installing "yelp" to actually install it but installing an application to only install the wrapper.
On Tue, 2010-05-25 at 15:58 -0400, Matt McCutchen wrote:
On Tue, 2010-05-25 at 20:22 +0100, Matthew Garrett wrote:
We discussed this issue at the fesco meeting today. The net outcome was that it's currently impractical to require that all packages that use yelp depend on it. However, requiring all yelp-using apps to integrate support for telling the user what's wrong may be unreasonable.
Long-term, it would be nice for this to integrate with PackageKit somehow. Short-term, the simplest solution would seem to be to provide a stub package that provides: yelp and a yelp binary, and then have that binary do nothing other than tell the user that they need to install yelp. Spins would then be at liberty to choose whether to provide the "real" yelp or the stub version. Once that's implemented dependencies can be added.
Does anyone have any objection to this approach?
We would have to ensure that (1) "yum install yelp" chooses the real package rather than the stub and (2) the real package can be installed on a system containing the stub without causing a file conflict.
An alternative would be to provide a wrapper script that runs yelp if present or otherwise tells the user to install it, and have applications require the wrapper package. We could either give the wrapper script a different name and patch all applications to run that name or rename the real yelp executable and have all callers go through the wrapper. I don't see any way to avoid patching all the application packages to require the wrapper package rather than "yelp", given that we want installing "yelp" to actually install it but installing an application to only install the wrapper.
With the latest compare_providers¹ this should be fairly easy. We just have yelp-nothing (Provides: yelp) which installs a simple binary that says yelp isn't there and a "yelp" package which is the real thing. Then "yum install yelp" will install the pkg. yelp, and "yum install blah" will install yelp-nothing as a dep.
¹ http://yum.baseurl.org/wiki/CompareProviders
On Tue, 2010-05-25 at 16:54 -0400, James Antill wrote:
On Tue, 2010-05-25 at 15:58 -0400, Matt McCutchen wrote:
An alternative would be to provide a wrapper script that runs yelp if present or otherwise tells the user to install it, and have applications require the wrapper package. We could either give the wrapper script a different name and patch all applications to run that name or rename the real yelp executable and have all callers go through the wrapper. I don't see any way to avoid patching all the application packages to require the wrapper package rather than "yelp", given that we want installing "yelp" to actually install it but installing an application to only install the wrapper.
With the latest compare_providers¹ this should be fairly easy. We just have yelp-nothing (Provides: yelp) which installs a simple binary that says yelp isn't there and a "yelp" package which is the real thing. Then "yum install yelp" will install the pkg. yelp, and "yum install blah" will install yelp-nothing as a dep.
I feel like taking advantage of a yum feature to make the "yelp" name do something different as a dependency than as a "yum install" argument is a hack and will only cause confusion down the road, whereas changing the application dependencies to yelp-nothing would be the right thing to do.
On 25 May 2010 20:22, Matthew Garrett mjg59@srcf.ucam.org wrote:
Long-term, it would be nice for this to integrate with PackageKit somehow. Short-term, the simplest solution would seem to be to provide a stub package that provides: yelp and a yelp binary, and then have that binary do nothing other than tell the user that they need to install yelp. Spins would then be at liberty to choose whether to provide the "real" yelp or the stub version. Once that's implemented dependencies can be added.
I could easily provide a simple binary to call in this instance to automatically install it if it's not found. It probably needs to be a little more generic than just the "yelp" case tho. Maybe this belongs in the toolkit (e.g. the toolkit calls to PackageKit so the the help type functions just work). If we can do this without patching applications then that would be best obviously.
I don't think just providing a note "help is not available" is particularly useful.
Richard.
devel@lists.stg.fedoraproject.org