Description of problem: The xpaint RPM package claims it requires emacs. If that is really so, it's a bug to require a mega-editor, and it should be weaned away from it. (It also claims it requires xpaint-devel, which seems doubtful.) Version-Release number of selected component (if applicable): xpaint-2.8.7.3-1.fc12 How reproducible: Steps to Reproduce: On a system without emacs: 1. rpm --test --install xpaint-2.8.7.3-1.fc12.i686.rpm Actual results: error: Failed dependencies: emacs is needed by xpaint-2.8.7.3-1.fc12.i686 xpaint-devel = 2.8.7.3-1.fc12 is needed by xpaint-2.8.7.3-1.fc12.i686 Expected results: No such bloated requirements. Additional info: xpaint seems to work without emacs (i.e., when installed with --nodeps). Requiring xpaint-devel seems dubious, but would be acceptable; requiring emacs is not.
xpaint can compile C plugins on the fly, and that it is why it requires xpaint-devel (tab options -> C script Editor). To create these C scripts, one can use an external editor (tab File), which is by default emacs. This default was chosen upstream.
I tried to run the xpaint option "C script editor", and this is possible, even with an uninstalled emacs!
Noticed this comment after filing bug 559946: > Requiring xpaint-devel seems dubious, but would be acceptable; No, it is not acceptable. First of all, all -devel packages ought to stay fully optional. Secondly, there is no point in splitting off files into a separate xpaint-devel package just to create a strict dependency on that package. This is broken.
(In reply to comment #3) > Noticed this comment after filing bug 559946: > > > Requiring xpaint-devel seems dubious, but would be acceptable; > > No, it is not acceptable. First of all, all -devel packages ought to stay fully > optional. Secondly, there is no point in splitting off files into a separate > xpaint-devel package just to create a strict dependency on that package. This > is broken. This has been exaustively discussed during the review of this package. xpaint allows the compilation of plugins written in C on the fly. This is why the devel package is required. Of course, there could not be any devel package, but the reviewers though that having one would be more appropriate. Regarding emacs, it is just an editor for editing plugin's code. It can be anything, vi, gedit, whatever... I just kept the default used upstream. Some people like emacs, other don't.
*** Bug 559946 has been marked as a duplicate of this bug. ***
Reviewer here. 2 things. 1. You may as well merge the -devel package, since it's not like anyone's going to use xpaint without it's contents. I was wrong there. 2. could the emacs call be replaced with gedit, or something else more common and smaller? Not vi, you need something with a gentler learning curve, since this is a paint program, not a dev tool. . .
The review request is: bug 526651 It points out that other distribution don't ship a -devel package either. You could still create a virtual Provides: xpaint-devel%{?_isa} = %{version}-%{release} in main "xpaint" package. But to create a separate xpaint-devel package only for a superfluous strict dependency is broken. > Regarding emacs, it is just an editor for editing plugin's code. 1) It's optional. 2) "xv" is also a default in xpaint without that you hardcode it as a strict dependency. 3) You could patch xpaint to evaluate $EDITOR instead of using only a hardcoded "emacs".
Ehm, make that: Provides: xpaint-devel = %{version}-%{release} %if "no%{?_isa}" != "no" Provides: xpaint-devel%{?_isa} = %{version}-%{release} %endif
Michael, I discussed this package with Hans de Goede during quite some time, although his name is not on the review process. This was the best solution we got, because this is one of the 1% of packages that do not fit in the template people are used to. Therefore, I would not like to change the package structure now. Nonetheless, I will update xpaint to 1.8.7.13 soon. I will remove emacs dependency, because xpaint really does not depend on emacs at all. This dependency is there only to make sure the user has a default editor installed. I personally do not think emacs is a burden, but the community seems not to agree with me. Furthermore, I am sure Richard Stallman will not mind if we remove emacs from the spec file ...
Sorry, I mean update to 2.8.13.1
xpaint-2.8.13.1-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/xpaint-2.8.13.1-1.fc11
xpaint-2.8.13.1-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/xpaint-2.8.13.1-1.fc12
> I discussed this package with Hans de Goede during quite some time, And still the current packaging is broken.
* https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages plus: * rpmlint -i xpaint-2.8.13.1-1.fc12.i686.rpm xpaint.i686: E: devel-dependency xpaint-devel Your package has a dependency on a devel package but it's not a devel package itself. is reason enough to not violate the guidelines, but create a virtual -devel package in the base package instead.
Perhaps xdg-open could be used instead of a hardcoded editor or $EDITOR? xpaint is an X application, not an xdg application, but I guess the xdg dependency would be smaller and more flexible than gedit or emacs. Could we patch xpaint to disable on-the-fly compilation if /usr/include/xpaint/xpaint.h isn't available? Perhaps that patch would be so simple that we can carry it even if upstream won't?
Michael's correct wrt -devel pkg here. If it cannot be made optional, then don't make a -devel subpkg, it's as simple as that (imo). Per the referenced guideline: A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel. notice the "not needed for the base package..." part. :)
+1 Michael and Rex.
I will merge the devel package, but I hope that the "include" symbolic link, when replaced by a real directory, will not give me a big head ache ...
It shouldn't IIRC, though going the other way is a nightmare, see gallery2.
That would be an issue entirely unrelated to merging the -devel package files, since the symlink exists already: $ rpmls -p ./updates/packages/xpaint-2.8.7.3-1.fc12.i686.rpm | grep ^l lrwxrwxrwx /usr/share/xpaint/include
(In reply to comment #18) > I will merge the devel package, but I hope > that the "include" symbolic link, when replaced by a real directory, > will not give me a big head ache ... I would not change that part, it still makes sense to keep the .h files under /usr/include, even if they go into the main package.
xpaint-2.8.13.1-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/xpaint-2.8.13.1-3.fc11
xpaint-2.8.13.1-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/xpaint-2.8.13.1-3.fc12
I think I fixed all of the open bugs. I hope this new release pleases either Greeks or Trojans. Thanks for the many suggestions.
I am closing this bug, because it has been fixed in xpaint-2.8.13.1-3.fc12