gnome-base/gvfs-1.4.3 does not depend on app-mobilephone/obex-data-server configure result is: ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-udev --disable-bash-completion --enable-archive --enable-avahi --enable-obexftp --enable-cdda --enable-fuse --enable-gdu --disable-gconf --enable-gphoto2 --enable-gudev --enable-hal --enable-http --enable-keyring --enable-samba --enable-gtk-doc ... gvfs configuration summary: gio module directory : ${exec_prefix}/lib/gio/modules FTP/HTTP/WebDAV support yes ObexFTP support yes Samba support: yes FUSE support: yes CDDA support: yes Gphoto2 support: yes archive support: yes GConf support: no DNS-SD support: yes Build HAL volume monitor: yes (with fast init path: yes) Build GDU volume monitor: yes GNOME Keyring support: yes Bash-completion support: no Reproducible: Always
RDEPEND=" ... bluetooth? ( >=app-mobilephone/obex-data-server-0.4.5 dev-libs/dbus-glib net-wireless/bluez dev-libs/expat ) ... " G2CONF="${G2CONF} ... $(use_enable bluetooth obexftp) ..." I kinda fail to understand the point of this bug.
It does: bluetooth? ( >=app-mobilephone/obex-data-server-0.4.5 dev-libs/dbus-glib net-wireless/bluez dev-libs/expat ) Simply enable USE="bluetooth" Regards
(In reply to comment #1) > RDEPEND=" > ... > bluetooth? ( > >=app-mobilephone/obex-data-server-0.4.5 > dev-libs/dbus-glib > net-wireless/bluez > dev-libs/expat ) > ... " > > G2CONF="${G2CONF} > ... > $(use_enable bluetooth obexftp) > ..." > > I kinda fail to understand the point of this bug. > fail to understand what? this is result of configure with $(use_enable bluetooth... ./configure --enable-bluetooth configure: WARNING: unrecognized options: --enable-bluetooth checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk ... skip ... !!! configure: WARNING: unrecognized options: --enable-bluetooth !!! unrecognized options: --enable-bluetooth understand?
(In reply to comment #2) > It does: > bluetooth? ( > >=app-mobilephone/obex-data-server-0.4.5 > dev-libs/dbus-glib > net-wireless/bluez > dev-libs/expat ) > > Simply enable USE="bluetooth" > > Regards > # cat /var/db/pkg/gnome-base/gvfs-1.4.3/USE archive avahi bash-completion bluetooth cdda doc elibc_glibc fuse gdu gnome-keyring gphoto2 hal http kernel_linux samba udev userland_GNU x86
PS. may be i post too few info... steps to reproduce: 1. emerge -C obex-data-server 2. modify ebuild: delete obex-data-server dependency 3. USE=bluetooth emerge gvfs result: build successfull
Sigh... Maybe if you did stick into your Summary something like "gnome-base/gvfs-1.4.3 - unrecognized options: --enable-bluetooth" instead of the completely misleading statement about *dependencies* then it would not confuse the hell out of everyone reading this bug. Please fix the bug summary.
(In reply to comment #6) > Sigh... Maybe if you did stick into your Summary something like > "gnome-base/gvfs-1.4.3 - unrecognized options: --enable-bluetooth" instead of > the completely misleading statement about *dependencies* then it would not > confuse the hell out of everyone reading this bug. Please fix the bug summary. > summary is correct. gnome-base/gvfs-1.4.3 really do not depend on app-mobilephone/obex-data-server, see my post above...
Eh... > ObexFTP support yes And why the install succeeds even if you uninstall it is this: $ cat INSTALL: The ObexFTP backend requires the obex-data-server D-Bus service in addition to the dependencies listed in the configure. See: http://wiki.muiline.com/obex-data-server So, the ebuild is entirely correct, it does --enable-obexftp when USE=bluetooth is set. INVALID bug. If you want to bug someone, then bug upstream about their incomplete (broken) autotools check.
configure.ac <snip> dnl *** Check if we should build with obexftp backend *** dnl ***************************************************** AC_ARG_ENABLE(obexftp, [ --disable-obexftp build without ObexFTP backend]) msg_obexftp=no OBEXFTP_LIBS= OBEXFTP_CFLAGS= if test "x$enable_obexftp" != "xno"; then PKG_CHECK_EXISTS(dbus-glib-1 bluez >= 4.0, msg_obexftp=yes) dnl Make sure we have expat AC_CHECK_LIB(expat, XML_ParserCreate_MM, [ AC_CHECK_HEADERS(expat.h, have_expat=true, have_expat=false) ], have_expat=false) if test "x$msg_obexftp" = "xyes" -a "x$have_expat" = "xtrue"; then PKG_CHECK_MODULES(OBEXFTP, dbus-glib-1 bluez >= 4.0) AC_SUBST(OBEXFTP_LIBS) AC_SUBST(OBEXFTP_CFLAGS) msg_obexftp=yes AC_DEFINE(HAVE_OBEXFTP, 1, [Define to 1 if ObexFTP is going to be built]) XML_CFLAGS="" XML_LIBS="-lexpat" else msg_obexftp=no fi fi </snip> ^^^ The above is broken, since it checks for dbus-glib and bluez, not for obex dbus support (provided by /usr/share/dbus-1/services/obex-data-server.service) So, one way to check this would be something like dbus_service_dir=`pkg-config --variable=session_bus_services_dir dbus-1` [ -f $dbus_service_dir/obex-data-server.service ] || <some fail action here> translated to the autotools foo. I don't have time for that ATM.
(In reply to comment #9) > configure.ac > > <snip> > dnl *** Check if we should build with obexftp backend *** > dnl ***************************************************** > AC_ARG_ENABLE(obexftp, [ --disable-obexftp build without ObexFTP > backend]) > msg_obexftp=no > OBEXFTP_LIBS= > OBEXFTP_CFLAGS= > > if test "x$enable_obexftp" != "xno"; then > PKG_CHECK_EXISTS(dbus-glib-1 bluez >= 4.0, msg_obexftp=yes) > > dnl Make sure we have expat > AC_CHECK_LIB(expat, XML_ParserCreate_MM, > [ AC_CHECK_HEADERS(expat.h, have_expat=true, have_expat=false) > ], > have_expat=false) > > if test "x$msg_obexftp" = "xyes" -a "x$have_expat" = "xtrue"; then > PKG_CHECK_MODULES(OBEXFTP, dbus-glib-1 bluez >= 4.0) > AC_SUBST(OBEXFTP_LIBS) > AC_SUBST(OBEXFTP_CFLAGS) > > msg_obexftp=yes > AC_DEFINE(HAVE_OBEXFTP, 1, [Define to 1 if ObexFTP is going to be built]) > XML_CFLAGS="" > XML_LIBS="-lexpat" > else > msg_obexftp=no > fi > fi > </snip> > > ^^^ The above is broken, since it checks for dbus-glib and bluez, not for obex > dbus support (provided by /usr/share/dbus-1/services/obex-data-server.service) > > So, one way to check this would be something like > > dbus_service_dir=`pkg-config --variable=session_bus_services_dir dbus-1` > [ -f $dbus_service_dir/obex-data-server.service ] || <some fail action here> > > translated to the autotools foo. I don't have time for that ATM. > gvfs not uses obex-data-server library/headers, etc for building obex-data-server library/headers not need for gvfs at runtime. then no dependency on obex-data-server. configure.ac is not broken. >The ObexFTP backend requires the obex-data-server D-Bus service in >addition to the dependencies listed in the configure. obex-data-server D-Bus __service__ in this service can be provided by any other package. this like mercurial: it does not depend on svn but svn should be installed if we need svn repository conversion
(In reply to comment #10) To quote once again: <snip> The ObexFTP backend *requires* the obex-data-server D-Bus service in addition to the dependencies listed in the configure. See: http://wiki.muiline.com/obex-data-server </snip> So, the dependency MUST be there if you enable the bluetooth flag, end of story. If you dislike the dependency, then kindly disable the USE flag and move on, there's absolutely nothing to be fixed here. And if you still dislike this, go talk to upstream about your obex-data-server phobia. And no, mercurial does not provide support for OBEX.
(In reply to comment #11) > (In reply to comment #10) > To quote once again: > > <snip> > The ObexFTP backend *requires* the obex-data-server D-Bus service in > addition to the dependencies listed in the configure. See: > http://wiki.muiline.com/obex-data-server > </snip> > > So, the dependency MUST be there if you enable the bluetooth flag, end of > story. If you dislike the dependency, then kindly disable the USE flag and move > on, there's absolutely nothing to be fixed here. And if you still dislike this, > go talk to upstream about your obex-data-server phobia. i has no obex-data-server phobia. gvfs compiles fine with --enable-obexftp flag and uninstalled obex-data-server. gvfs works fine without obex-data-server (but obexftp shure not work without it). no compiletime dependency, no runtime dependency. > And no, mercurial does not provide support for OBEX. mercurial is example of behavouir. what about app-mobilephone/obexd?
(In reply to comment #12) > gvfs compiles fine with --enable-obexftp flag and uninstalled obex-data-server. > gvfs works fine without obex-data-server (but obexftp shure not work without > it). no compiletime dependency, no runtime dependency. Yeah, and tons of other stuff compiles fine with --disable-dependency-tracking if you uninstall the dependency, but is broken on runtime, hence - the dependency. Disabling the compile-time tracking is just a mean to avoid checks that are needless for Gentoo but generally required upstream. How on earth can you talk about no runtime dependency, it's explicitely required and *documented* to be requires, as I've quoted multiple times already. So no, it DOES NOT run fine without it, the feature doesn't work at all without obex-data-server. And that feature is enable - amazingly - via --enable-obexftp configure option. So, people who enable the USE flag expect it to Just Work (TM). No cryptic dbus errors, no broken functionality, no need to dig why it doesn't work, no need to install additional stuff. It must Just Work. Why do you keep beating a dead horse and why don't you switch that flag already for this ebuild or globally if you don't want obexftp. > And no, mercurial does not provide support for OBEX. > > mercurial is example of behavouir. That example is plain wrong. Mercurial has no --enable-subversion or whatever similar configure option. If it had one, subversion would be an optional dependency because otherwise the configure option makes no sense. > what about app-mobilephone/obexd? What about it? Does it provide DBUS obex service? Does it use the API compatible with gvfs design? [1] Talk with upstream about it. They specifically require obex-data-server as it is now. [1] http://www.mail-archive.com/openobex-users@lists.sourceforge.net/msg01284.html
