[arch-dev-public] request for dbus in core
A while ago I got a request from Thomas to make a stripped down dbus package that does not depend on libx11 so he could use it for wpa_supplicant which is also in core. As more and more services start to interact with this dbus thing, I'd like to move the new dbus-core package into core. This pulls in one extra dependency from extra, which is expat at this moment. The new dbus package contains only the x11 parts of dbus and stays in extra.
On Sat, Oct 11, 2008 at 3:09 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
A while ago I got a request from Thomas to make a stripped down dbus package that does not depend on libx11 so he could use it for wpa_supplicant which is also in core. As more and more services start to interact with this dbus thing, I'd like to move the new dbus-core package into core. This pulls in one extra dependency from extra, which is expat at this moment.
The new dbus package contains only the x11 parts of dbus and stays in extra.
my support for [core], as an upcoming netcfg version will take advantage of the wpa_supplicant dbus interface. Though, why did you split it rather than just using optdepends. Only one very minor utility needed libx11 and you'd only be using it if you had X installed.
On Sat, 2008-10-11 at 22:49 -0700, James Rayner wrote:
On Sat, Oct 11, 2008 at 3:09 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
A while ago I got a request from Thomas to make a stripped down dbus package that does not depend on libx11 so he could use it for wpa_supplicant which is also in core. As more and more services start to interact with this dbus thing, I'd like to move the new dbus-core package into core. This pulls in one extra dependency from extra, which is expat at this moment.
The new dbus package contains only the x11 parts of dbus and stays in extra.
my support for [core], as an upcoming netcfg version will take advantage of the wpa_supplicant dbus interface.
Though, why did you split it rather than just using optdepends. Only one very minor utility needed libx11 and you'd only be using it if you had X installed.
What's the policy on cross-repository dependencies these days? Is it normal to have core packages makedepending on packages from extra or community?
On Sun, Oct 12, 2008 at 3:25 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Sat, 2008-10-11 at 22:49 -0700, James Rayner wrote:
On Sat, Oct 11, 2008 at 3:09 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
A while ago I got a request from Thomas to make a stripped down dbus package that does not depend on libx11 so he could use it for wpa_supplicant which is also in core. As more and more services start to interact with this dbus thing, I'd like to move the new dbus-core package into core. This pulls in one extra dependency from extra, which is expat at this moment.
The new dbus package contains only the x11 parts of dbus and stays in extra.
my support for [core], as an upcoming netcfg version will take advantage of the wpa_supplicant dbus interface.
Though, why did you split it rather than just using optdepends. Only one very minor utility needed libx11 and you'd only be using it if you had X installed.
What's the policy on cross-repository dependencies these days? Is it normal to have core packages makedepending on packages from extra or community?
Frowned upon. It still happens, but we try to do it as little as possible. Jason
On Sun, Oct 12, 2008 at 5:25 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Sat, 2008-10-11 at 22:49 -0700, James Rayner wrote:
On Sat, Oct 11, 2008 at 3:09 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
A while ago I got a request from Thomas to make a stripped down dbus package that does not depend on libx11 so he could use it for wpa_supplicant which is also in core. As more and more services start to interact with this dbus thing, I'd like to move the new dbus-core package into core. This pulls in one extra dependency from extra, which is expat at this moment.
The new dbus package contains only the x11 parts of dbus and stays in extra.
my support for [core], as an upcoming netcfg version will take advantage of the wpa_supplicant dbus interface.
Though, why did you split it rather than just using optdepends. Only one very minor utility needed libx11 and you'd only be using it if you had X installed.
What's the policy on cross-repository dependencies these days? Is it normal to have core packages makedepending on packages from extra or community?
Hmmm maybe we can/should flesh that out. If it's a makedepend/optdepend, I don't see a direct problem with it. It feels a little funny, but other than that, I don't see anything technically wrong with it. Besides that, I'd support dbus in core. Split or not, it should be ok. And expat in core seems slightly logical too
participants (4)
-
Aaron Griffin
-
James Rayner
-
Jan de Groot
-
Jason Chu