app-editors/bluefish links against specifically gnome-base/gnome-vfs and gnome-base/libgnomeui if they exist. bluefish can link solely against gnome-base/gnome-vfs to provide support for reading/writing files on GNOME's virtual filesystems. bluefish can link against gnome-base/libgnomeui for using some common GNOME user interface functions. The gnome-base/gnome-vfs linkage is totally usable in its own right, and as such doesn't need wrapping in to a "use gnome" test IMO. However, the gnome-base/libgnomeui quite obviously warrants the use of the gnome use flag IMO[1]. I wanted to see some consensus on whether a gnome-vfs(or some other name, yet same meaning) flag could be added to support gnome-base/gnome-vfs without the need for all the other gnome-base/libgnomeui stuff before I took the time to cut patches... or fix it yourself if you come to a conclusion and can spare 15 minutes ;) 1. Support for gnome-base/libgnomeui would force gnome-base/gnome-vfs as well, because of the deps set in gnome-base/libgnomeui. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I don't think adding a gnome-vfs-flag is needed. I'd suggest having both handled by the gnome-useflag. Beside that, the problem is that there's no way to enable/disable these features with configure-options, so to fix this we would need to patch the configure-script (or let upstream fix this). If you have a working patch, please attach it to this bug.
First up sorry for the delay, holiday season. The attached patches should fixes the dependencies, and without adding a new gnome-vfs flag as you suggested. It isn't the prettiest solution, but it renders the smallest patch for files/ by skipping all the whitespace changes. The patches have only been compile tested, but they are really simple. I have to admit now that if I'm the only person touched by this bug it isn't worth fixing it with optional GNOME support, might as well just correct the dependencies statically. [I'm going to have to keep my local ebuilds in the overlay regardless. It is way too late in the day to make the GNOME VFS support pull in all the extra GNOME libs just for a few VFS modules that require auth for us, as it has been deployed for 3 months already.] -- The attached patches should fixes the dependencies, and without adding a new gnome-vfs flag as you suggested. It isn't the prettiest solution, but it renders the smallest patch for files/ by skipping all the whitespace changes. The patches have only been compile tested, but they are really simple. I have to admit now that if I'm the only person touched by this bug it isn't worth fixing it with optional GNOME support, might as well just correct the dependencies statically. [I'm going to have to keep my local ebuilds in the overlay regardless. It is way too late in the day to make the GNOME VFS support pull in all the extra GNOME libs just for a few VFS modules that require auth for us, as it has been deployed for 3 months already.]
Created attachment 65835 [details, diff] bluefish-1.0.2-gnome.patch
Created attachment 65836 [details, diff] bluefish-gnome.patch
Did you send your patches to the bluefish-devs? 1.0.4 still has no configure-options for that stuff. I don't want to fix such minor stuff inside ebuilds, but imho it should be fixed upstream.
(In reply to comment #5) > Did you send your patches to the bluefish-devs? 1.0.4 still has no > configure-options for that stuff. Nope, I really don't consider this to be a bug with the upstream source. It does exactly what it sets out to do, in what is probably the most obvious way. > I don't want to fix such minor stuff inside ebuilds, but imho it should be > fixed upstream. The whole purpose of this bug report was the broken dep tree in portage, all I wanted to do with the attached patches was offer up the simplest/smallest(obviously not cleanest) way to support choice in the event that you decided you didn't want to fix the dep tree by adding a heap of gnome libs(especially considering what it actually achieves wrt bluefish). Really I'm quite ambivalent about the issue as far as portage is concerned.
(In reply to comment #5) > Did you send your patches to the bluefish-devs? 1.0.4 still has no > configure-options for that stuff. > I don't want to fix such minor stuff inside ebuilds, but imho it should be > fixed upstream. Well there is at least for libgnomeui: --without-libgnomeui disable libgnomeui detection
Created attachment 73652 [details, diff] patch agains bluefish-1.0.4.ebuild With this patch I was able to reduce the ldd /usr/bin/bluefish output as follows. USE="gnome" with libgnomeui installed pena ~ # wc -l bluefish.after 49 bluefish.after pena ~ # wc -l bluefish.with 61 bluefish.with
Seems you are missing quite a few deps in bluefish. Use the following script to test. http://dev.gentoo.org/~betelgeuse/scripts/checkdeps
I've now added a gnome useflag for the libgnomeui-dep, if you want gnome-vfs also configurable, please fill a bug upstream.
