You are not logged in.
This was brought to my attention by Vince from ostalk.org
http://www.techsnap.co.uk/archived/images/archpm.png
Now ive traced back most of the dependencies like this
gtk-qt-engine pulls libbonoboui
libbonoboui pulls libgnomecanvas and libgnome
libgnome pulls gvfs
gvfs then pulls bluez and gnome-disk-utility
gnome-disk-utility pulls device-kit-disks
device-kit-disks pulls parted
So at which point was the mistake made? I mean does gtk-qt-engine really require libbonoboui, does libbonoboui really require libgnome, etc.
Surely at some point optdepends are being called as depends because gtk-qt-engine should most certainly not pull parted or bluez.
Edit: use a thumbnail for big images - Allan
Last edited by Allan (2010-03-25 01:47:52)
Offline
Haha bluetooth kernel module and partition editor for gtk-qt-engine
Last edited by cesura (2010-03-25 00:11:37)
Offline
itsbrad212: fyi bluez has nothing to do with kernel modules. It provides the userspace bluetooth libraries and utilites.
Bluetooth kernel modules are provided by the kernel26 package.
Offline
No mistake made as far as I can see. Its possible, of course, for gvfs not to pull in bluez/gnome-disk-utility. Just means that some parts of it will not work, even IF bluez/gnome-disk-utility are installed (AFAIK).
Its a binary distribution, packages used for a variety of things need to be 'general-purpose'. If you don't want bluez/gnome-disk-utility I'd looke at either modifying the libgnome or gvfs PKGBUILD and the ./configure lines.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Why not just have things as optionl depends instead of depends, that way the user can decide what he needs for himself? Ive seen this done with other packages where it just lists all the optional dependencies after installation.
Last edited by tjwoosta (2010-03-25 00:29:47)
Offline
this is the same discussion from the youtube rant thread. i've already covered this subject and why is happening.
http://bugs.archlinux.org/task/17598
Last edited by wonder (2010-03-25 00:37:33)
Give what you have. To someone, it may be better than you dare to think.
Offline
So shouldnt gvfs just be an optdepend of libgnome then? Not everyone using libgnome needs gnome-open, for example in this case Vince is a kde user who just wants his gtk-qt-engine. Where does bluez fit into the picture, or parted?
Something about this just doesnt add up.
Offline
So shouldnt gvfs just be an optdepend of libgnome then? Not everyone using libgnome needs gnome-open, for example in this case Vince is a kde user who just wants his gtk-qt-engine. Where does bluez fit into the picture, or parted?
Something about this just doesnt add up.
so you are an Vince evangelist? if he really want this "issue" to be fixed, he should do something about this.
1) use abs to get rid of useless dependencies
2) figure a schema in which gvfs is involved. like splitting gvfs in multiple packages. (patches welcomed)
Give what you have. To someone, it may be better than you dare to think.
Offline
Vince has already done something about it, its just an example.
I mean no disrespect, Im just trying to figure out why things are the way they are. If there are useless dependencies that can be gotten rid of, why are they not optional?
Offline
Vince has already done something about it, its just an example.
I mean no disrespect, Im just trying to figure out why things are the way they are. If there are useless dependencies that can be gotten rid of, why are they not optional?
because, like you do, only words, not facts
Give what you have. To someone, it may be better than you dare to think.
Offline
because, like you do, only words, not facts
You lost me there. What?
Offline
wonder wrote:because, like you do, only words, not facts
You lost me there. What?
you missed my point.
2) figure a schema in which gvfs is involved. like splitting gvfs in multiple packages. (patches welcomed)
Give what you have. To someone, it may be better than you dare to think.
Offline
In other words, someone needs to do the work.
Let's say there's two groups of users using libgnome. One uses gnome, so he needs what we'd call full functionality. One only needs it via gtk-qt-engine, so he needs a very small subset. This can be solved by:-
1. Making both use the same libgnome package, which provides full functionality (current status).
2. Making two libgnome packages, one with full functionality and one with only the subset gtk-qt-engine needs. Basically double the work.
3. Splitting libgnome into 2 parts which complement each other. Much more than double the work.
Arch uses 1. generally, unless someone in the community is willing to do the work to maintain packages for 2. or 3.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
In other words, someone needs to do the work.
Let's say there's two groups of users using libgnome. One uses gnome, so he needs what we'd call full functionality. One only needs it via gtk-qt-engine, so he needs a very small subset. This can be solved by:-
1. Making both use the same libgnome package, which provides full functionality (current status).
2. Making two libgnome packages, one with full functionality and one with only the subset gtk-qt-engine needs. Basically double the work.
3. Splitting libgnome into 2 parts which complement each other. Much more than double the work.Arch uses 1. generally, unless someone in the community is willing to do the work to maintain packages for 2. or 3.
Ok, I see what your saying. I was just thinking more along the lines of
4. Change the gvfs dependency in libgnome pkgbuild to an optdepend. Users who dont need it could simply ignore it, while those who do would see it as an optdepend and install it seperately. Libgnome would contain all the same libraries, but only certain ones would work right unless the user installs the optdepend.
I can see now how this might complicate things for gnome users though.
Offline
If you can "pacman -Rd gvfs" and the libgnome package still works, then an optdepend would be appropriate. Hint: It does not work...
Basically that leave option #3 above. Another option is for people to use ABS and makepkg for what they need or go elsewhere.
Offline
First of I'm an idiot... How i didn't see this thread is beyond me. Sorry for the reposting of the thread...
So anyway, I want to say that this really bothers me as KDE user and I do hope something good will come out of this and on the end everything will just work.
And I'm willing to get this solved.
I'll research what can it be done to make a #3 happen.
I think the best option is that KDEmod, which is KDE centric "spin-off" from Arch edits their current gtk-qt-engine package so that it uses only things that are needed (that also gose for the dependencies of the dependencies).
I'll report when I'll get somewhere...
Arch x86_64 ATI AMD APU KDE frameworks 5
---------------------------------
Whatever I do, I always end up with something horribly mis-configured.
Offline
I think the best option is that KDEmod, which is KDE centric "spin-off" from Arch edits their current gtk-qt-engine package so that it uses only things that are needed (that also gose for the dependencies of the dependencies).
I'll report when I'll get somewhere...
The problem isn't so much with the gtk-qt-engine package, honestly. Probably something like 'libgnome-qt-engine' package with only the ./configure options needed would be okay, but don't expect it to ever get on Arch's official repos without good justification. In that sense yes, I think the KDEmod repos are more suitable.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
I've been informed on KDEmod forums that there's another gtk-qt-engine package named gtk-kde4 which is supposedly better.
If not anything else it has a lot less dependencies.
pacman -Qi gtk-kde4
Name : gtk-kde4
Version : 0.9.3-2
URL : http://kde-look.org/content/show.php?content=74689
Licenses : GPL
Groups : None
Provides : gtk-qt-engine
Depends On : kdebase-workspace gtk-engines
Optional Deps : None
Required By : None
Conflicts With : None
Replaces : None
Installed Size : 1804,00 K
Packager : PKGBUILD.com Build Server
Architecture : x86_64
Build Date : sob 09 jan 2010 03:02:33 CET
Install Date : čet 25 mar 2010 15:39:52 CET
Install Reason : Explicitly installed
Install Script : No
Description : Allows you to change style, icons, font of GTK applications in KDE4.
Last edited by Primoz (2010-03-25 14:50:05)
Arch x86_64 ATI AMD APU KDE frameworks 5
---------------------------------
Whatever I do, I always end up with something horribly mis-configured.
Offline
You have to understand that gtk-qt-engine is both for gnome people that use qt apps and kde people that use gtk apps. Therefore, both sides must be bothered a bit. If you only belong to one group of people, a not-so-universal package will work better for you, such as gtk-kde4.
As a side note, look what happens if I try to install gtk-qt-engine from my mostly gnome desktop:
$ LANG=C pacS gtk-qt-engine
resolving dependencies...
warning: provider package was selected (phonon-gstreamer provides phonon-backend)
looking for inter-conflicts...
Targets (13): clucene-0.9.21b-1 strigi-0.7.2-2 libiodbc-3.52.7-3
virtuoso-6.1.0-1 soprano-2.4.1-1 qca-2.0.2-2
polkit-qt-0.95.1-1 phonon-gstreamer-4.4.0-1 phonon-4.4.0-1
shared-desktop-ontologies-0.3-1 attica-0.1.2-1 kdelibs-4.4.1-1
gtk-qt-engine-1.1-2
Total Download Size: 28.31 MB
Total Installed Size: 119.54 MB
Proceed with installation? [Y/n]
It takes even more disk space for gnome users
Offline
Try qtcurve; its imho the best way to get consistent look&feel.
Offline
File a bug about libbonoboui dependencies in gtk-qt-engine. As far as I know, libbonoboui is optional at compile time. Given the fact that libbonoboui is deprecated for years, I wouldn't care about the fact that gtk-qt-engine can't style bonoboui toolbars.
Offline
Hi JGC, its deprecated but still in use some places. For example Evolution are just completing the move away from it....
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
I think that gtk-kde4 doesn't work; or at least it doesn't work with bespin (well the gtk-qt-engine didn't work either...).
Arch x86_64 ATI AMD APU KDE frameworks 5
---------------------------------
Whatever I do, I always end up with something horribly mis-configured.
Offline