After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342435 - system-tools-backends now depends on dbus
system-tools-backends now depends on dbus
Status: RESOLVED OBSOLETE
Product: jhbuild
Classification: Infrastructure
Component: module sets
unspecified
Other opensolaris
: Normal normal
: ---
Assigned To: James Henstridge
Jhbuild QA
Depends on: 342638
Blocks:
 
 
Reported: 2006-05-20 17:14 UTC by James Andrewartha
Modified: 2006-08-10 19:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description James Andrewartha 2006-05-20 17:14:22 UTC
This dependency just appeared:

http://jhbuild.bxlug.be/builds/2006-05-20-0000/logs/system-tools-backends/#clean
Comment 1 Frederic Peters 2006-05-24 07:59:08 UTC
This is actually not straight DBus but its Perl bindings; this requires Perl module support in jhbuild, you should set the bugzilla "depends on" to 342638 (as I don't have enough priviledges to do this).
Comment 2 James Henstridge 2006-06-19 05:45:17 UTC
Well, the perl module support is in now.

I guess some env vars are needed for system-tools-backends to see the module though.
Comment 3 Frederic Peters 2006-06-19 09:55:03 UTC
Sorry I forgot the environment variable in the <perl> patch; here it is:

+        # PERL5LIB
+        perl5lib = os.path.join(self.prefix, 'lib', 'perl5')
+        addpath('PERL5LIB', perl5lib)

Comment 4 James Henstridge 2006-06-19 12:36:57 UTC
Okay, cool.

I assume that hunk is for Config.setup_env.

Feel free to add it and fix up system-tools-backends to use the HEAD branch again.
Comment 5 James Henstridge 2006-06-21 01:45:30 UTC
Elijah: you just reverted Frederic's changes after we'd got the infrastructure in place to build Perl modules.

Could you explain why you don't want people to test the development version of gnome-system-tools when building the development module set?
Comment 6 Elijah Newren 2006-06-21 01:52:55 UTC
Sure.  Note though, that I reverted it once before as well -- check the ChangeLog.  :)

Anyway http://mail.gnome.org/archives/release-team/2006-June/msg00007.html and the various other emails from that thread is the detailed explanation; in summary, perl-net-dbus should not be a hard dependency of the desktop suite unless brought up on d-d-l and agreed upon by the community.  So far, the Gnome 2.15.x releases have gone out with older versions of gnome-system-tools; if the hard dependency isn't removed and isn't brought up and resolved on d-d-l, the newer version of Gnome system tools will not be used in Gnome 2.16.x and is thus the wrong version to test.
Comment 7 James Henstridge 2006-06-21 06:15:52 UTC
When you first switched to the gnome-2-14 branch, you were fixing a build breakage (gnome-system-tools not building without Net::DBus and jhbuild not having the infrastructure to build that dependency).  That is an understandable change.

The second time you were reverting to an old branch when the maintainer is intending to use the main branch for the next release when that branch was buildable.

The release-team thread seemed to be arguing over semantics:

 * system-tools-backends depending on Net::DBus is bad because it adds a
   dependency on a binding.
 * system-tools-backends including Net::DBus would be okay though, even
   though it is adding a dependency on a binding.
Comment 8 Frederic Peters 2006-08-10 19:28:37 UTC
http://mail.gnome.org/archives/desktop-devel-list/2006-July/msg00705.html:

> Note that the gnome-system-tools gnome-2-14 branch will be used for
> Gnome 2.16, and thus liboobs isn't relevant until at least Gnome 2.18.

Release team spoke so the issue is no longer a problem for gnome 2.16 module set.

Marking the bug as obsolete (since 'FUTUREBUG' is not available).