dependency hell: balsa, a Gnome app, depends on qt

segmental · 2005-01-01 05:14:46

I know dependency checking is there to help us out,
but sometimes the web of dependencies becomes a bit bizarre.

The dependency chain for balsa to qt goes something
like this:

balsa -> gpgme -> gnupg2 -> pinentry -> qt

As it turns out, "pinentry" contains only three passphrase
dialogs, one written in ncurses, one in gtk and one in qt.

So to get this qt dialog, which you do not actually need if either
ncurses or gtk is installed, you have to download the entire 15
mb qt library?

Maybe I am missing something. The logic of all of this escapes me.

xerxes2 · 2005-01-01 15:49:47

you can install packages without dependencies using the 'd' option,

# pacman -Sd pinentry

contrasutra · 2005-01-01 16:01:00

This is unfortunately the problem with binary distributions. Arch builds with the common options on all packages. This means sometimes the package won't have the feature you need, or it will have a feature that adds bloat.

It seems only the recent version of pinentry started depending on QT. But, since the purpose of pinentry is to provide a password dialog for multiple toolkits, it would make sense to build it with every option available.

I think your best choice would be to recompile pinentry to your needs. Consider using srcpac; it can recompile the package automatically at every update.

Also, I really don't think a 15MB lib is that big of a deal, especially one as common as QT. These aren't the days of 3GB hard drives.

segmental · 2005-01-01 17:34:16

Of course it is easy to rebuild pinentry. It is just that these
dependency relationships seem fantastical when they first
appear. And tracing them down is time-consuming.

As for installing with -d, that works for the moment but
the unresolved dependency reappears whenever you
do an -Syu update.

I took the easy way out -- I just installed sylpheed instead.

sarah31 · 2005-01-01 18:45:35

Packages that do not have a a runtime dependency requirement should just throw a waring upon install (ie. such and such has compatability with qt or gtk to have this feature use you must have qt or gtk installed)

I had the same issues with sylpheed-claws/sylpheed one of the mainatainers add a whole whack of depends that were modular but he made them install/runtime depends. I preferred claws but was told to go use sylpheed instead.

Moral of this story. maqintainers are not always right. Runtime depends means they should be included in the depends. If it is modular then DON'T include the depend but give the warning that it does have the feature if you install something else.

miqorz · 2005-01-01 22:02:13

Am I the only one who rebuilds the packages that include dependencies I don't like?

I rebuilt E16, XMMS and mplayer to remove lots of crap I don't like.

segmental · 2005-01-01 22:06:41

I think that dependencies should be restricted to
what is actually required for a piece of software to
run, excluding whatever extra features might be
bundled with it.

In the case of balsa, it does not require qt, pinentry
gpgme or gnupg2 to run. Gnupg support is a nice
addon, but it is not an essential part of the software.

miqorz · 2005-01-01 22:33:11

That's not a very good idea at all.

Arch's goal is to make it easier for people. Installing those packages and finding out they must rebuild for features they may need just because you don't want extra dependencies is a bit selfish and a general bad practice for Arch.

Just rebuild the package.

vicious · 2005-01-02 00:22:35

Solution is simple: split pinentry into pinentry-gtk, pinentry-qt and pinentry-ncurses. Or enable USE-FLAGS suggested by rehrca.

dp · 2005-01-02 00:36:32

vicious wrote:

Solution is simple: split pinentry into pinentry-gtk, pinentry-qt and pinentry-ncurses.

post a bug @ bugs.archlinux.org for this

sarah31 · 2005-01-02 03:38:38

vicious wrote:

Solution is simple: split pinentry into pinentry-gtk, pinentry-qt and pinentry-ncurses. Or enable USE-FLAGS suggested by rehrca.

if you want something like that use Debian .... you can learn just how stupid dependency solving can get.

Like is said the EASIEST solution is to have additional features designed as modules by the developers. Modules that can be included but turned on and off by installing the supporting software for those modules.

Take transcode. It actually only has a few runtime depends every other feature is modular. To build you need the extra stuff installed but a user does not need all of it to run it. (actually i think arch's transcode even includes depends that are NOT runtime depends).

Common featues shoud be included by default but it is better if these features are modular. It makes packaging easier and management easier as well (ie no need to rebuild packages)

sarah31 · 2005-01-02 03:44:39

miqorz wrote:

That's not a very good idea at all.
Arch's goal is to make it easier for people. Installing those packages and finding out they must rebuild for features they may need just because you don't want extra dependencies is a bit selfish and a general bad practice for Arch.
Just rebuild the package.

I don't see anywhere that Arch's goal is to make it easier for people. If ti were they would aim to be point and click. and gui this and thats or drag and drop. It isn't though. In fact arch aims for the ADVANCED/Experienced user which usually precludes Easier in many cases.

I am all for building only basic packages that include all the basic feature that add no kludge to the system. I think it is prumtuous and selfish to do either fatten an app or have itr so sparse that it performs only to a fraction of its potential.

Like I said above I believe in modularity. That way it can be built feature rich but not have to run feature rich.

miqorz · 2005-01-02 05:58:04

Well I didn't mean the Arch distro in general was made to make it easier.

But Pacman certainly is, and removing all the neat plugins in stuff like mplayer and xmms would piss off alot of people. Because it's in the nature of those apps to be able to play just about anything.

Forcing people to rebuild packages of a binary distro for features ones expects from a package is just absolutely redundant.

I've only rebuilt packages to remove features and that is alot simpler than adding support for something.

I HATE the fact the Arch guys enable esd to every package they can but I'm not going to complain based on my personal hate for the thing.

Xentac · 2005-01-02 18:56:48

segmental wrote:

I think that dependencies should be restricted to
what is actually required for a piece of software to
run, excluding whatever extra features might be
bundled with it.
In the case of balsa, it does not require qt, pinentry
gpgme or gnupg2 to run. Gnupg support is a nice
addon, but it is not an essential part of the software.

The problem is then the maintainers get bug reports saying, "I use gnupg, it needs to be compiled in!" In this case, you actually need the gpgme libs installed on the system because the balsa binary is linked to them. Even if you don't use the feature, if balsa is compiled with it, you need it around all the time.

Maybe you should patch all of these apps to support dynamic runtime linking...

JGC · 2005-01-06 14:35:02

When I build packages, I think: "is it a runtime dependency and if not, is it useful?"

Like when you build evolution: gnome-pilot support. You build it with gnome-pilot installed, you run it without, still works. If you want to have gnome-pilot support, just install it, you needed it anyways.

Or DBUS:
It provides QT, GTK, Python, whatever bindings. I list them all as build dependencies and have none of them as run dependency. Why? The DBUS daemon runs without them, and the bindings shit is nice with all the dependencies, but if you create a python program that uses dbus python bindings, wouldn't you have python installed then?

With this library and its dialogs, QT, GTK and Ncurses should be a build dependency. The library has no use without programs calling that lib, and guess what? Those programs depend on either QT, GTK or Ncurses...

Arch Linux

#1 2005-01-01 05:14:46

dependency hell: balsa, a Gnome app, depends on qt

#2 2005-01-01 15:49:47

Re: dependency hell: balsa, a Gnome app, depends on qt

#3 2005-01-01 16:01:00

Re: dependency hell: balsa, a Gnome app, depends on qt

#4 2005-01-01 17:34:16

Re: dependency hell: balsa, a Gnome app, depends on qt

#5 2005-01-01 18:45:35

Re: dependency hell: balsa, a Gnome app, depends on qt

#6 2005-01-01 22:02:13

Re: dependency hell: balsa, a Gnome app, depends on qt

#7 2005-01-01 22:06:41

Re: dependency hell: balsa, a Gnome app, depends on qt

#8 2005-01-01 22:33:11

Re: dependency hell: balsa, a Gnome app, depends on qt

#9 2005-01-02 00:22:35

Re: dependency hell: balsa, a Gnome app, depends on qt

#10 2005-01-02 00:36:32

Re: dependency hell: balsa, a Gnome app, depends on qt

#11 2005-01-02 03:38:38

Re: dependency hell: balsa, a Gnome app, depends on qt

#12 2005-01-02 03:44:39

Re: dependency hell: balsa, a Gnome app, depends on qt

#13 2005-01-02 05:58:04

Re: dependency hell: balsa, a Gnome app, depends on qt

#14 2005-01-02 18:56:48

Re: dependency hell: balsa, a Gnome app, depends on qt

#15 2005-01-06 14:35:02

Re: dependency hell: balsa, a Gnome app, depends on qt

Board footer