You are not logged in.

#1 2005-12-03 09:31:05

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Dependency hell

Hi

I really thought it wouldn't happen to me in Arch, but it did. Look at this:

checking package integrity... done.
loading package data... done.
checking for file conflicts... done.
[..]
installing docbook-xml... done.
installing docbook-xsl... done.
installing scrollkeeper... done.
installing gnome-common... done.
installing orbit2... done.
installing libbonobo... done.
bonobo-activation-server: no process killed
installing gconf... done.
installing shared-mime-info... done.
installing gnome-mime-data... done.
installing smbclient... done.
installing gnome-vfs... done.
upgrading xine-lib... done.

I mean what gives?! I never wanted any gnome parts on my system (since I use KDE) and to my suprise, after the usual pacman -Syu I get it!

After investigating for a moment it's all clear:

Name           : gnome-vfs
[..]
Required By    : xine-lib
Conflicts With : gnome-vfs-samba
Description    : The GNOME Virtual File System

Yea I use xine-lib but never ever before it had deps upon gnome-vfs! I knwo that to some people this is useful, but to me it's not! And I can't understand why it's a full-time dependency. Just because someone wants this sort of feature (because I doubt it's crucial for the xine-libs to work at all) doesn't mean that everyone who uses xine-lib needs to have gnome-vfs on their system!

Well I tried to sort some of this dependency hell before to cut out things that I don't really need or want. I added:

IgnorePkg   = aalib cyrus-sasl esd gnokii gpgme imlib mdnsresponder ruby

to pacman.conf but that didn't work really. During upgrades it complained that the following package is required and is on the ignore list. I  don't really program in ruby and I don't want it to be downloaded and installed each time I upgrade my system and kde is updated.

Yea, maybe I'm dumb and there is a way of handling this, but I've both read the manual for pacman and search the forum and I didn't see any information that could help me. If I'm missing something, please let me know (as I'm getting desperate on this one).

But if not, I think that some sort of "optional dependency" field should be made for packages in their PKGBUILDS as pacman is becomming more and more like a rpm hell.

Offline

#2 2005-12-03 09:55:36

ferkulat
Member
Registered: 2005-12-03
Posts: 7

Re: Dependency hell

i had the same surprise today hmm
i thought: ok i'll make my own pkgbuild

in the depency line i deleted gnome-vfs

to the configure line i added "--disable-gnome"

maybe "--disable-gnome" its not neccessary, if u dont have any gnome stuff installed.
But i got an error during compiling, about missing ljasper.
After
         pacman -S jasper
it compiled and made the package.
Thats why i think even the official PKGBUILD should add the jasper depency.

Offline

#3 2005-12-03 10:02:35

stavrosg
Member
From: Rhodes, Greece
Registered: 2005-05-01
Posts: 330
Website

Re: Dependency hell

Hello.

Binary packages have this sort of "problems" . They have certain features (and, thus, dependencies) included, and others omitted.

Just because someone wants this sort of feature (because I doubt it's crucial for the xine-libs to work at all) doesn't mean that everyone who uses xine-lib needs to have gnome-vfs on their system!

Indeed, but the packager decided that it is better for most users to be used rather than not, so he included this dependency as well.
If you really don't want certain dependencies on certain packages on your system, then the way to go is to recompile through abs (that's what it is for anyway).

It isn't rpm hell, really. It is due to the "one package per application" part of the arch system, and I don't really see this changing.

cheers!
Stavros

Offline

#4 2005-12-03 10:04:11

stavrosg
Member
From: Rhodes, Greece
Registered: 2005-05-01
Posts: 330
Website

Re: Dependency hell

ferkulat wrote:

i had the same surprise today hmm
i thought: ok i'll make my own pkgbuild

in the depency line i deleted gnome-vfs

to the configure line i added "--disable-gnome"

maybe "--disable-gnome" its not neccessary, if u dont have any gnome stuff installed.
But i got an error during compiling, about missing ljasper.
After
         pacman -S jasper
it compiled and made the package.
Thats why i think even the official PKGBUILD should add the jasper depency.

This is a bug that you should report to http://bugs.archlinux.org wink

Offline

#5 2005-12-03 10:09:15

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Re: Dependency hell

Yea. In the end, I did the same thing. Recompiled xine-lib from abs.

But it's not my point here. There is a lot of useless junk installed each time I upgrade. For example samba, ruby,... I could go on. I don't need these things. They're worthless to me.

The point is, I can't find a way to tell pacman not to install things I don't need - even if they're deps for some packages I use. In Slackware, KDE is compiled with samba support, but it doesn't mean you have to have samba package installed. If you want to use kde's samba bindings it's simple: install samba package. If you don't need it, don't install it. Nobody forces you to do it.

Don't get me wrong, I love pacman. But being forced to install packages I don't want or need is just wrong. I thought the idea behind Archlinux is to keep everything simple. But it keeps on getting all complicated hmm

Offline

#6 2005-12-03 10:15:42

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Re: Dependency hell

stavrosg wrote:

Indeed, but the packager decided that it is better for most users to be used rather than not, so he included this dependency as well.
If you really don't want certain dependencies on certain packages on your system, then the way to go is to recompile through abs (that's what it is for anyway).

It isn't rpm hell, really. It is due to the "one package per application" part of the arch system, and I don't really see this changing.

True, but this is a huge dependency. I mean, it's quite counterintuitive to force a user to download 11 packages just to get one feature. And it's not a typical gnome package, it's a library used by many programs in different DE's.

I wouldn't mind if it was some sort of a optional dependency, where pacman would ask me:

This packages has a feature that depends on thispkg. It's not crucial for the application but you might need this feature. Do you want to install it?

And then give some sort of a parameter in pacman.conf to specify optional dependencies to ignore automatically.

That would be a really fine and clean solution to the problem.

Offline

#7 2005-12-03 11:45:24

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: Dependency hell

Well I reckon this is contrary to the Arch Packaging Standards, which state:

Any optional dependencies that aren't needed to run the package or have it generally function shouldn't be included, but a warning message inside the .install file should echo something like: "To enable SMB support, download the Samba package."

Offline

#8 2005-12-03 12:03:21

ferkulat
Member
Registered: 2005-12-03
Posts: 7

Re: Dependency hell

Any optional dependencies that aren't needed to run the package or have it generally function shouldn't be included

hmm if i read this, why gnome-vfs is then included and a depency?

I made my xine-lib without gnome and it works anyway.

Like Neuro I do not like it to install several packages i dont need in any other way than for just a (in most cases unneeded) gimmik.

I couldnt compile xine-lib without package "jasper", but the binary xine-lib  seemed to work anyway.

Could it be possible that xine-lib has a compiled support for gnome but doesnt depend on it to work without gnome-vfs?

Then the depency entry for gnome-vfs could be deleted.

Offline

#9 2005-12-03 12:42:33

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Re: Dependency hell

Apart from the fact that some packages have dependencies which are just too broad, I think that there should be a way to tell pacman not to install dependencies I explicitly stated not to.

An example:
I don't use ruby, I don't want ruby, I don't use anything that uses ruby in any way. Yet, I can't remove it!

pacman -R ruby
error: this will break the following dependencies:
  ruby: is required by amarok-base-mysqlfree
  ruby: is required by kdebindings

Yea, I know that it's used by some plugins. But I don't have these plugins and I propably never will. And if I will need to use one, I'll install ruby myself.

True, I can remove ruby using pacman -Rdf ruby. But each time I do pacman -Syu, ruby is installed hmm
I can't put ruby into IgnorePkg because pacman won't upgrade/install kdebindings then. It'll fail miserably:

pacman -S kdebindings
:: kdebindings-3.5.0-2: is up to date.  Upgrade anyway? [Y/n] y
kdebindings requires ruby, but it is in IgnorePkg.  Install anyway? [Y/n] n
error: cannot resolve dependencies for "kdebindings"

I currently have 374 packages in my system. Just by looking at them, I can say that I don't need at least 10% of them. And propably that's underestimated.

As I said.. i love pacman and the way it's handling packages. It's simple and straighforward. But... some more control wouldn't hurt, would it?

I don't know, maybe a IgnoreDep flag in pacman.conf or anything like that?

Offline

#10 2005-12-03 13:33:08

MartinZ
Member
From: Chiloé, Chile
Registered: 2005-06-10
Posts: 379

Re: Dependency hell

I totally agree with this.

gnome-vfs isn't a dependency of xine-lib, it shouldn't be there. I had to compile the package myself, because i want to keep my system as cleaner as possible, and i really don't need all that gnome stuff.


All your base are belong to us

Offline

#11 2005-12-03 14:26:57

nightfrost
Member
From: Sweden
Registered: 2005-04-16
Posts: 647

Re: Dependency hell

The way I see it, additional options to pacman wouldn't be needed if packages were made properly, in accordance with arch packaging standards (as quoted by tomk). So why not just try to get the official PKGBUILDs straightened up?

Offline

#12 2005-12-03 14:32:33

kth5
Member
Registered: 2004-04-29
Posts: 657
Website

Re: Dependency hell

xine-lib may not depend on gnome-vfs - no matter what - simply because xine-lib is in current it may not have a dep which is in extra. file a bug or something. ;p


I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell

Offline

#13 2005-12-03 15:11:44

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Re: Dependency hell

nightfrost wrote:

The way I see it, additional options to pacman wouldn't be needed if packages were made properly, in accordance with arch packaging standards (as quoted by tomk). So why not just try to get the official PKGBUILDs straightened up?

True, but I guess this works only for the typical one program/library pacakges. It fails with packages like kdebindings or kdenetwork. One can image how pacman prints out loads of information like "install package this to do that" when installing kde.

However a modification to pacman and makepkg could solve this situation.

Example:

Name           : kdenetwork
Version        : 3.5.0-2
Provides       : None
Depends On     : gnutls>=1.2.4 kdebase>=3.5.0 kdelibs>=3.5.0 openslp perl-io-socket-ssl ppp qca-tls rdesktop wireless_tools
                 x-server
Required By    : None
Conflicts With : None
Description    : KDE Networking Programs.

So kdenetwork could depend directly on gnutls, kdebase, kdelibs, openslp, perl-io-socket-ssl and qca-tls, while optionally depend on: ppp, rdesktop, wireless_tools (as the last ones are just features while the other are needed for basic communication like SSL/TLS)).

Then if one installs kdepackages, pacman prompts weather to install these optional deps or not. During upgrades users are only asked for new optional dependencies or the not installed reviously ones.
The user would be allowed to set IgnoreOptionalDep so if a package opt-depts on one of the packages stated in this attricute, he's not prompted at all.

But, if the user chooses to install a packages taht directly depends upon one of the packages stated in IgnoreOptionalDep, the dependency is installed regardless.

This would be a really clean way of handling such a problem. What do you think?

Offline

#14 2005-12-03 15:28:18

nightfrost
Member
From: Sweden
Registered: 2005-04-16
Posts: 647

Re: Dependency hell

Hmm... that sounds very lean if you ask me. I can imagine that there might be fear of losing simplicity, at least to some extent, should this be implemented. 

Also (after a moment's thought), wouldn't it be necessary to rewrite many PKGBUILDs in order to introduce  opt-deps vs. deps?

Perhaps it would be enough to let pacman parse the config file for IgnoreDep?

Offline

#15 2005-12-03 16:37:15

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Re: Dependency hell

nightfrost wrote:

Hmm... that sounds very lean if you ask me. I can imagine that there might be fear of losing simplicity, at least to some extent, should this be implemented.

True, this might mean a bit more complication, but I see it much more useful (while being at least complicated to the same extent) as for eaxmple the 'conflicts with' or 'provides' fields. And, after all, this would provide means to make the system much more simple and less bloated. So I don't think that the "losing simplicity" argument is valid here.

Also (after a moment's thought), wouldn't it be necessary to rewrite many PKGBUILDs in order to introduce  opt-deps vs. deps?

I don't think that checking if the changed (perhaps due to package upgrade)  or a newly added PKGBUILD could use the new field would be much of a hassle. No one said that all packages should be immidietly audited due to addition of the new field. That would be just insane. wink

Perhaps it would be enough to let pacman parse the config file for IgnoreDep?

Sure, that wouldn't require much work AFAIK. But it's a more of a dirty workaround than a clean sollution, since packages that really require dependencies stated in IgnoreDep would get crippled and stop working.

Offline

#16 2005-12-03 18:01:05

ozar
Member
From: USA
Registered: 2005-02-18
Posts: 1,686

Re: Dependency hell

Neuro wrote:

Hi

I really thought it wouldn't happen to me in Arch, but it did. Look at this:

checking package integrity... done.
loading package data... done.
checking for file conflicts... done.
[..]
installing docbook-xml... done.
installing docbook-xsl... done.
installing scrollkeeper... done.
installing gnome-common... done.
installing orbit2... done.
installing libbonobo... done.
bonobo-activation-server: no process killed
installing gconf... done.
installing shared-mime-info... done.
installing gnome-mime-data... done.
installing smbclient... done.
installing gnome-vfs... done.
upgrading xine-lib... done.

I mean what gives?! I never wanted any gnome parts on my system (since I use KDE) and to my suprise, after the usual pacman -Syu I get it!

Same here... it was quite a shock to be planning on doing a routine system upgrade to find that all this new stuff was going to be installed.  I have no need for most of it, so didn't upgrade.   :x


oz

Offline

#17 2005-12-03 19:05:18

MartinZ
Member
From: Chiloé, Chile
Registered: 2005-06-10
Posts: 379

Re: Dependency hell

Cool, deps fixed.
xine-lib now doesn't include gnome-vfs as dependency, verything as before.

Thanks guys.     tongue


All your base are belong to us

Offline

#18 2005-12-03 19:14:41

MartinZ
Member
From: Chiloé, Chile
Registered: 2005-06-10
Posts: 379

Re: Dependency hell

I was upgrading my system and got this well-known message:

Note kipi-plugins runtime depends are:
==> k3b,mjpegtools,imagemagick,kdebase,dcraw


So I thought a better way to solve the problem posted above

In my opinion, a clean and simple solution would be this 2 points:
1. IgnoreDep option for pacman.conf
2. This messages without coma, so you can just copy/paste the whole line if you want. So would be something like:

Note kipi-plugins runtime depends are:
==> k3b mjpegtools imagemagick kdebase dcraw

All your base are belong to us

Offline

#19 2005-12-03 19:39:36

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Re: Dependency hell

MartinZ wrote:

I was upgrading my system and got this well-known message:

Note kipi-plugins runtime depends are:
==> k3b,mjpegtools,imagemagick,kdebase,dcraw


So I thought a better way to solve the problem posted above

In my opinion, a clean and simple solution would be this 2 points:
1. IgnoreDep option for pacman.conf
2. This messages without coma, so you can just copy/paste the whole line if you want. So would be something like:

Note kipi-plugins runtime depends are:
==> k3b mjpegtools imagemagick kdebase dcraw

Yea it's simple, but I wouldn't call that clean. There are 2 disadvangages:
1. Not all packages have such notes. For example: kdenetwork
2. Suppose one would like to instal a package which directly depends upon something stated in IgnoreDep may render the installed program useless (as the really needed dep is not resolved)

Of course a simple IgnoreDep is easier to implement than the whole "optional dependency" thingy, but having pacman recognise what is and what is not optional could allow us to avoid problems stated above.

But that simple IgnoreDep concept is better than nothing smile

Offline

#20 2005-12-04 20:49:55

MartinZ
Member
From: Chiloé, Chile
Registered: 2005-06-10
Posts: 379

Re: Dependency hell

1. Of course, every single package should include those notes
2. Pacman may give you an advertisement "x dep would not be satisfied. Force?"


All your base are belong to us

Offline

#21 2006-01-25 08:22:48

Neuro
Member
From: Poland
Registered: 2005-10-12
Posts: 352

Re: Dependency hell

*bump*

It's sad to see this discussion die out. I'd like to ask the devs if there are any plans to address these problems? Anything like the IgnoreDep flag in pacman.conf oroptional_dep field in PKGBUILDS?

Offline

#22 2006-01-25 10:43:37

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: Dependency hell

The devs aren't always around here - hardly ever, AFAIK. Post it on Flyspray as a feature request - they'll definitely see it that way.

Offline

Board footer

Powered by FluxBB