gconf dependency should depend on gnome use flag
Created attachment 207662 [details, diff] libgsf-1.14.16.ebuild.patch
No it shouldn't, read ChangeLog
read changelog, no explanation on why making libgsf hard dependend on gconf/orbit. Have an overlay, removed gconf hard dependency, it compiled and worked. Please put back gconf dep under gnome use flag or provide proper explanation or pointers on proper explanation.
Sorry it was in ebuild: > # FIXME: gconf is actually automagic and only needed for thumbnailer
proper explanation please
(In reply to comment #6) > proper explanation please Please tone down your attitude here. Bugzilla is a work tool, not a soap box to vent your frustrations. So please, chill down or I will contact user-rel. Thanks
Documentation about what is an automagic dependency: http://www.gentoo.org/proj/en/qa/automagic.xml Now gconf is only used for a libgsf powered thumbnailer (that you will have to look for yourself), it could be made optional by most likely little work, but unfortunately I don't have the time to do it right now, that's why there is a FIXME, in the meantime, correctness of dependencies prevails.
(In reply to comment #8) > Documentation about what is an automagic dependency: > http://www.gentoo.org/proj/en/qa/automagic.xml > ... > FIXME, in the meantime, correctness of dependencies prevails. thx.
*** Bug 289891 has been marked as a duplicate of this bug. ***
Created attachment 207707 [details, diff] libgsf-1.14.16.ebuild.patch
Created attachment 207708 [details, diff] configure.in.patch quick fix for gconf dep
cleaner fix
Thank you.
Patch looks very good, might want to send it to Gnome's bugzilla. Thanks for cooking it up. Here are a few thoughts though (maybe upstream will have similar comments?) 1) use AC_HELP_STRING instead of AS_HELP_STRING (unless the latter is already used elsewhere). AS_ is a newer namespace and might require a newer autoconf. 2) make the default value "auto" instead of "check", that's what upstream Gnome projects usually have. Just for the consistency's sake. (FTR, the whole configure.in could use a _major_ clean up, it's completely foobar) Thanks again for the patch.
tiny spec: rename your patch specifically to the fixed bug, in this case for example libgsf-1.14.16-automagic-gconf.patch that's more clear for maintainance and when we clean the tree :)
Created attachment 207752 [details, diff] libgsf-1.14.16.ebuild.patch
Created attachment 207753 [details, diff] libgsf-1.14.16-automagic-gconf.patch
Created attachment 207756 [details, diff] libgsf-1.14.16-automagic-gconf.patch check -> auto
actually the patch should fail if gconf support is requested but not found. Otherwise it looks good.
Created attachment 207908 [details, diff] other-configure.patch
Created attachment 207910 [details, diff] other-configure.in.patch
Created attachment 207912 [details, diff] other-libgsf-1.14.16.ebuild.patch
To make autoreconf work on the cleaned configure.in, gconf.m4 must be installed. Is there any way to make autoconf bypass the missing bits from gconf.m4? If not, configure would be patched and autoreconf not run without gconf installed.
(In reply to comment #24) > To make autoreconf work on the cleaned configure.in, gconf.m4 must be > installed. Is there any way to make autoconf bypass the missing bits from > gconf.m4? If not, configure would be patched and autoreconf not run without > gconf installed. > AFAIK, no. But maybe, gconf.m4 will be packed into tarballs. See https://bugzilla.gnome.org/show_bug.cgi?id=595495 .
So what will the resolution on this be?
So will this patch be applied in portage? Has the patch been submitted upstream?
Tested on a new installation of laptop. I notice that FreeBSD did the similar trick. If the patch is not accepted by upstream, hope this new ebuild be applied to portage. At least, you said FIXME:)
Patch added to tree without a bump. Thanks for reporting and the patch.
re-opening this bug since the patch was applied blindly and actually breaks on system without gconf installed. Please the autofoo part could be written in a sexier way probably.
(In reply to comment #30) > re-opening this bug since the patch was applied blindly and actually breaks on > system without gconf installed. Please the autofoo part could be written in a > sexier way probably. > Typically, we've just to make a copy of gconf-2.m4 in m4/ , and include this file (gconf-2.m4) in the patch... the rest looks good for me (but I'm wrong probably)
Created attachment 214286 [details, diff] libgsf-1.14.16-gconf-automagic.patch something like that...
Could you please update the patch and/or apply it?
+ 13 Jan 2010; Gilles Dartiguelongue <eva@gentoo.org> + -libgsf-1.14.11.ebuild, libgsf-1.14.16.ebuild, + +files/libgsf-1.14.16-automake-fixes.patch, + files/libgsf-1.14.16-gconf-automagic.patch, metadata.xml: + Restore gnome-vfs support, move thumbnail support to its own USE flag, fix + missing autoreconf dependencies, fix missing intltoolize call, rework + automagic patch, bug #289856 and fix bug #298813. Clean up old revision. + Thanks for reporting.
