Bug#493090: libwxgtk2.8-0: unwanted dependency on libgconf
* Ryan Niebur <email@example.com> [090805 10:23]:
> or is the reason just that you are anti-GNOME?
Could you please stop that "If you question what we do you are
against us"? If you troll everbody until they have a hate for GNOME
you might end up with everybody either loving what GNOMES does or having
so many bad experiencies they feare everything GNOME related. But the
world would be better for all if some constructivity would be allowed.
Some points in trying to get some more arguments in this discussion:
1) gconfd is not something everyone wants to run and people should have
It's a kind of user-daemon running in the background, so people have a
right to be uneasy about it. Also at least in the past its mode of
starting and especially stopping by programs in an environment not fully
GNOME was just horrible. (Last time I had it installed with etch,
I needed special scripts to terminate the hundreds of instances that
were started but never stopped).
2) I wanted to write that the problem is not libgconf but the daemon
package. But I do no longer know if this is true, as the daemon
seems to be moved to the library package some time ago. (Having a
library would make it harder for people to filter things, but I think
it is totally acceptable to only have a library but nothing started by
> is it possible to build with wxMediaCtrl disabled?
> anyway, I'm assuming that some package uses wxMediaCtrl.
> and I really don't want to go through the trouble to find out.
Someone suggested before to make a seperate media package. If this
also moved the gstreamer dependency to that package, that would be
a nice step to reduce the dependencies of the libwx package quite a bit,
making much more people profit from it.
Some interesting point to decide how "reasonable" that is would be some
information, how easy such a split would be. (I cannot find any
information about this in this bug). If you do not know this, you could
ask for help or patches.
Hoping for less angry replies,
Bernhard R. Link