What dependency hell??
 

Hi,

I recently tried to install slackware on a laptop with a 2gb hdd and actually got surprised that I could boot the computer and get a shell. Got a few libs problems and X won't start but I'll have to investigate this...
So since I have been doing full installs so far, and that I'd like to install squid on my router/firewall/wap, I thought that I could trim down on stuff that I don't really use, with only 8 gb hdd any extra bit of space I might get would be welcome, note that this box uses slackware 10.2 with kernel 2.6.18. Of course I backed up some of the most important config files and all before I fired pkgtool!! To my great disappointment my system was still working after uninstalling stuff and rebooting the computer. It's headless so I can't see if I get error messages at boot or not, but it works!!

My questions really is, how come is the system still working? I thought uninstalling stuff with pkgtool wasn't suppose to work very well since it doesn't dependency checks!?

Shortly said, you didn't remove anything dangerous :) try and remove glibc or something "important"..

Don't tempt him... bad experience about removing glibc... truly broke system :)

In my experience, you can only truly appreciate the frustration of "dependency hell" with a RPM based distro. ;) Slack's just somehow too clever that way.
As for removing glibc, I'm pretty sure that would screw even Debian, dependency resolving or not (and no, I aint going to try it to find out) :)

Thanks for the input guys!!!

U all are right, I didn't try to remove glibc! Why? Well I can say that I am familiar enough with the system to know that this is not something that should be removed...

So lets say for instance that I keep uninstalling stuff via pkgtool apart from any libraries since they do seem to cause troubles.

Anyone tried this?

Why were you disappointed ?

No dependency checking doesn't mean you have to do a complete installation. It means you have to know what you're doing when you remove a package. Is this package used by another one that I want to keep ? If not then you can safely remove it.

You can do a minimal installation by not installing packages in E/, F/, K/, KDE/, KDEI/, T/, TCL/ and some in A/ and XAP/ directories.

Sounds like that well known parlour game where you keep removing blocks till the whole tower collapses. Must say, I've not tried that with my Linux box. Interesting concept though.

Yes I wish it could be that simple but the first time I tried not to do a complete installation I endend up with a system unusable. I am really interested to find out how to know which packages are used by others and which are not!!!

Wikipedia says:

High cohesion and low coupling are attributes of good design



Is that the case for slackware? I mean I know it's good design but is it high cohesion and low coupling??



yeah why not you know... Have to experiment and see =)

I agree that it's not easy to know which packages are used by others.

If your first interest is to know a generic way to know that, I can't answer (no magic formula here).

What I suggested is that you can safely remove applications that you don't want to use (and of course that you know about).

The directories I listed in my previous posts are some safe bets: if you don't use Emacs (E/), KDE (KDE/ and KDEI/) and if you are familiar with X applications (XAP/ : for example you may want xchat but not gaim, flubox as windows manager instead of xfce).

Also, if you're interested and have time, you can track the changelog of Slackware-current and you'll get lots of information about package dependencies as development of the next Slackware version progresses. It's a good way to learn (look at the changelog for Slack 11.0 for a preview of what will come).

Good idea!! thanks

Bugger,

I made my system unusable... but it doesn't look that's because of depencies though!

Anyone interested in this should not remove the sed(stream editor) package =) It's my fault anyway I haven't been very carefull ^^

Yeah, sed is pretty important... but check THIS out.

Boot a live-distro called Slax. Get a copy of the sed package for Slackware, and do something along the lines of the following:
installpkg -root /mnt/hda1/ sed*.tgz

And then reboot to Slackware. Problem fixed!

Even better, boot the original CD and reinstall what you need without reformatting.

Oooh look at that; I didn't know about installpkg -root. I just learnt something new. I usually chroot.

That's the beautiful part about Linux treating everything as a file... no funny registries or anything else to mess with.

I guess you could count ldconfig as something that would need to be run in the main distro... but ah well.

Ah thanks for all the good advices guys.

actually I was trying this on a laptop (before trying on the router) which hosts the installation cds on a windows partition. Since I do not have the docking station for the computer ( I only own a pcmcia cd drive), I have to resort to do an install via grub4dos.

It's a bit messy and I don't like the idea of sharing a hard drive with windows, but it was the only way for me to install linux on this when I bought that laptop, without spending extra money on a usb floppy...

Anyway I did a fresh install, trimmed some stuff off and now I even have x working on it ^^

I am trying to work out if dependencies really occur between programs that are closely related or not. Sorry if this sounds silly but I am just trying to make sense of all this, for example:

in slackware 11 there is a package called mod_ssl which is an apache module for ssl. So removing the apache package or the ssl package would prevent the mod_ssl package from running smoothly but wouldn't affect packages like xfce etc... Right????

I mean if they did it the other way around (which wouldn't make sense to me) that would be very complex...

Oh by the way wikipedia is of great help to find out what packages do what and sometimes they even talk about dependencies ^^

removing glibc is not that bad ;)
 

Hi

I accidentally removed glibc doing an experiment some months ago. I had to reinstall Linux on that machine and they paid me $150 to do it! (it was WhiteBox 3, I couldn't install a newer mc RPM so I got angry... Now it has Slackware and it works quite well)

That's uncommon, but I actually removed glibc and got paid for it. You never know.

Just think what they might have paid you for blowing the box up! :)

Has anyone got an idea as to if yes or not the extensions of gcc (fortran, ada, objective c) are needed to compile most programs please??

I reduced the size of my installation down to less than 900 megs. I think it's pretty decent and I'm sure there's a lot more stuff that I could do without...

That dependency thing was one of the reasons I wanted to move away from slackware and is a bad point that comes back very often when people come to criticise it. I have been a full time slack user for just around 6 months now and this was probably the easiest thing I've ever had to do on it, all you need is a brain and 2 fingers!!!
Frankly I am happy that I stayed with slackware it is not hard at all to do things manually, I actually broke my system once again today (couldn't locate libblkid at boot) and it was very easy to locate the package and reinstall it. It would have been even easier if I had written down what I was removing. It makes me even happier that I do not have to rely on automated bells and whistle to maintain my system!!!

No decent excuse not to give a go to slack IMO

In the Linux world, those languages aren't that common. I always leave them out and just install them later if I really need them.

What are you talking about?

The beauty of Slackware is that dependencies, if there are any, are in the program you are trying to compile.

If you do your homework, and read the docs for the program, there are no dependency issues. You would already have the programs needed.

Personnally, I have had 0 dep issues. Why? I read first...

Those people are not anyway near the majority. I have a full time job and am a full time student. I do not have enough time to read a manual to find dependencies, and then read those dependencies' manuals too, read them, and track so forth.

Dependency hell is caused when you attempt to install a package, to find you don't have a dependency, and then to find again that you don't have the dependencies for that particular dependency. It happens on all distros. Even Slackware. Even if you compile from source you still have to track dependencies. For example, try installing certain media players, or TICT(for the TI calculators). Even in slackware, even if compiled from source, you still have to track dependencies recursively.

That is why some people value distros like Debian that recursively search the dependencies for you.

That's why you get a feel for what kind of dependency hell you are about to go through. I know for most any program what kind of dependency tree I'll experience by browsing their site just a little bit.

And unless it is particularly esoteric, it is most definitely true that you'll never experience dependency hell because Slackware has pretty much every dependency you'll ever need.

If you are trying to install unknown binaries, that's your problem, not the distro's. Even Debian can't handle badly built packages.

If you haven't tried to use RedHat extensively, you have no clue what dependency hell means.

Absolutely, that was my point about RPM-based distros. The Slackware repositories contain all the info you need to track dependencies. It isn't hard but yes, it could be time consuming depending on the package.

I'm trying out Debian currently and installing software is a no-brainer but you still have to be very careful when removing anything and read what else is going to be taken away (aptitude wanted to remove the entire Gnome DE along with one small unwanted program).

Thanks more stuff I can trim :)


Fairy nuff if this is what it is for you! But it happens that slackware comes installed with most things I need and I rarely need extra packages (apart from drivers so far, madwifi, hostapd, wpa supplicant, speedtouch etc...) but I actually need to trim down and this is what gave me troubles with dependencies the first time I tried to slim it down!
Why? because I didn't read (as you said) and wasn't as familiar with it as I am now...

So please don't try to convince me on about what the beauty of slackware is, as it might be completely different to different people. What you call hell I call home!!! And I do not mean to offend you at all ;)

For the record, no auto dependencies checking is one thing I really like about slack, at least for a desktop.

If you need to know what an app depends on, you can use the ldd command.

# ldd `which abiword`

Or if an app is broken, can be fixed w/

# ldd `which abiword` | grep "NOT FOUND"

Then use your fav way to search the MANIFEST file. I like vim, so I do "vim MAN*", search, then hit "{", and there's the missing package.

If you're compiling from source, most authors mention all the deps in a small README, usually not much more than a page.

If your computer is too slow to compile from source, most maintainers at http://www.linuxpackages.net
are courteous enough to mention deps in the packages description.

As long as you do a full install of base and lib groups on the slack cd, should handle most cases. If you have to compile a library, remember to use...

./configure prefix=/usr ...

If need to see what's already installed from a package...

# cd /var/log/pack*
# grep "<search string>" *

If you need to, it's easy to reinstall a whole group on the slack cd...

# cd /mnt/cdrom/slack*/gnome/removepkg *.tgz
# installpkg *.tgz

Just don't remove the kernel, glib, gzip, or any standard tools or libs (you'll know what to keep from more experience.) But can always use the slack install CD to fix mistakes.

Overall, less complication IMO. But don't get me wrong, I've had good times w/ Debian and FreeBSD too. BTW, yes, "dependency hell" comes from redhat.

You have to be careful with aptitude since it uses the concept of "requested packages" -- anything pulled in as a dependency is not requested, and when you remove anything at all, it will want to also remove the unrequested packages.

This is handy if you want to try something out: you first mark all existing packages as "requested" then install the package you want to try (which may install dependencies). If you don't want to keep it, remove it with aptitude and everything that came with it will go as well.

But as you found out, it can be dangerous if you don't know how it works. Generally speaking, I don't use aptitude unless I have a special reason for doing so; I use apt-get.

Anyway, I hope I got this information right -- I don't have the aptitude man page handy since today I'm using slack :)

edit (to avoid a double post):
seandon4, that was a nice post ... I saved it because I'm sure I'll need that info someday.

Thanks for the info eerok :) . I use aptitude because it's supposed to be the preferred tool since Sarge but I can see the shortcomings there. Perhaps I'll keep it simple and use apt-get!

That is some very helpful information there, thanks a lot!!!

I went through the same process several time to get slackware running on an older laptop, and eventually I got it through trial and error, a good learning experience. Since then if I need something small, I just use Zenwalk and then add what I need.

Does anyone know which package contains the library libutempter.so.0 please?

Thanks

The install script for the utempter package in a/ disk set creates the link.

Thank you very much!!! I should have looked better...

I am now running slack on an old pentium 2 with a tiny 3 gigs hdd... When I bouhgt that laptop it had windows xp installed and took about 10 minutes to load the os and another 10 minutes to start IE :cry:

Now it's fast as hell and the OS lives on less than a gig of memory (including x etc!!!). Got to love it :)

I don't know if this would be helpful to anybody, but this is the set of packages I select when I install Slack. In addition to these, I install k3b and kernel-headers-2.6.18. I install a "barebnz" kernel without modules from a floppy. Later I build a real kernel and install many packages by compiling. I end up with a light, fast system. BTW Frankenputer and Franz are the names of my computers.

A. floppy, gawk, glibc-zoneinfo, gpm, infozip, (and on Frankenputer: cups)

AP. cdparanoia, cdrdao, cdrtools, diffutils, dvd+rw-tools, groff, man, man-pages, normalize, vorbis-tools, (and on Frankenputer: espgs, gimp-print, gnu-gs-fonts), (and on Franz: lm_sensors)

D. REMOVE: kernel-headers

F. (leave all as they are)

L. atk, cairo, expat, glib, glib2, glibc, gtk+, gtk+2, jre, libao, libart-lgpl, libidn, libjpeg, libmad, libmng, libmusicbrainz, libogg, libpng, libtiff, libungif, libvorbis, libxml2, libxslt, mpeg_lib, ncurses, pango, pcre, zlib (and on Frankenputer: libusb) (and on Franz: glut)

N. dhcpcd, nmap, ntp, tcpip, wireless-tools

X. (leave all as they are)

KDE. kdeaddons, kdeadmin, kdebase, kdegraphics, kdelibs, kdeutils, qt

Gosh something gave me quite a headache. Does anyone know what kernel headers are there for? I mean I know that they are needed (I kept getting errors with cpp while trying to ./configure squid without kernel headers) but is it some kind of thing that's used to compile the whole distribution??

I'm sure no expert in this but this is what works for me. You need kernel headers from somewhere to compile, and you should either use the 2.4 kernel headers that come in the "D" library, or the 2.6 headers from testing.

I use the 2.6.18 headers, and I'm running a 2.6.19 kernel.

Kernel headers? Its one of those things you never really think about. I got this quote from http://linux.maruhn.com

I just find it a bit odd that we have to keep some completely different (2.4.33 for instance)kernel headers files to build a 2.6 kernel...
It is certainly something that I never thought about :)

This website:

http://linux.maruhn.com/sec/kernel-headers.html

keeps some kernel headers but it seems a bit of a mess (unless it's me), it's all mixed up between different versions and might need a bit of patience to find the right files ^^

Chikne, the kernel headers on that website are debian. I wasn't suggesting you should use them, I was just quoting their explanation of kernel headers. They do seem a bit mixed up but, since debian apt resolves dependencies, it will automatically install the correct headers when you upgrade the kernel. Hence I don't suppose debian users are all that worried about the order of them.

I'm sure someone will correct me if I'm wrong but if you're downloading a new kernel for slackware you should be able to determine the correct kernel headers by looking for dependencies on the download site.

For example look at:

http://packages.slackware.it/browse....inux-2.6.17.13

The first thing is, you *don't* need kernel headers installed to compile kernel itself. All the relevant headers for the kernel being compiled come with sources for the kernel.
Kernel headers package is used for programs that link to some kernel stuff. The headers are put in the standard include path, so that compiler finds them easily. And you must note that external programs don't really need all the headers there. There are a *lot* of internal kernel structures that no other program should ever worry about them. That's why there are folks who do some "cleanups" of kernel headers to remove unnecessary stuff, and so on. There is a lot written somewhere in this forum about this subject. Search...

What you need to note is, that the majority of this headers are compatible between different kernel versions. If they weren't, you'd have to recompile everything that linked to the old kernel upon installing new one (most notably, glibc, but also nearly everything else). The main reason that kernel headers are not completely compatible, are new features and, from time to time, removal of obsolete legacy structures. In case you want to use the new features, it's often not enough to replace the headers, but also recompile glibc. And if your system uses some functions that are gone, you also have to recompile that stuff upon changing kernel (but I think that's a quite rare thing, you have to use an extremely outdated kernel to experience these problems).

So, as a logical conclusion of these facts, it is recommended to use the headers that the glibc was compiled against. In this way you achieve maximum coherence of your system. As in the case of slackware, glibc was compiled against 2.4.33 AND 2.6.xy headers (2.6 was used for NPTL support). So, if you *want* other programs compiled with NPTL, you use 2.6 headers, otherwise it's doesn't matter which you use.

This is, how I understand things. I know that I know very little, so feel free to correct me or enlighten me more! ;)

As a slack user, and a fedora user and an experienced developer, I am seeing a couple of different scenarios here with depenedencies. I recognize that there are libraries on linux called shared objects which are basically dll's in windows lingo. Lets say Program X uses method or function signature Y of shared object(s) Z on the system..

Now I have heard that in this scenario : Well that would ultimately be depeneded on the person writing Program X. But lets say that Program X depended on shared object(s) Z being on the system.

Lets say I want to install Program X, but I have a different version of shared object(s) Z on the system with either no function signature Y or changed function signatures. We all of a sudden have a problem, because Program X needs shared object(s) Z but all of the other programs that come with that distro happen to need that particular version of shared object(s) Z.

I suppose my question is, what is the frequency like for how often this happens? I personally haven't ran into this issue on slackware, but I haven't considered myself to really be self relying on slackware either to the point where I have fully installed everything that I need. I have only installed what I currently needed for whatever job that I have had to do. However for people that use it and no other OS, that might be a different story. I only ask that because of the alternative, such as fedora.

Fedora for the most part has the end user happier on how they manage their packages now. At any rate, programs are built exactly for that distro version and all programs are expected to just 'work'. It's quite simple. You download it, and just install it and it does what it needs to do for you to access and just use it. From a productivity standpoint, I see this as really being the way to go, and I can't see it going in another direction such as slackware, where you have to spend time typing in commands like ldd to find out what deps a program has and reading their site and their readme's and all that other BS as to where I should be able to just 'install' it. Quite simple.

I also say this because of Mac OS. Programs are installed as images and they are basically single folder installations that are dragged and dropped. Their dependencies are tightly nit but where it must make a system call , the OS is being managed to the point where you really don't run into dependency conflicts even across minor revisions, not necessarily revisions. I see fedora almost taking this philosophy and I think it's really working out for them.

If anyone has ever played around with InstallShield or Wise for Windows Installers or even just plain 'ol Windows Installer you will notice that shared objects (in slackware / linux terms) are revisioned and your program relys on those certain revisions. When you start overwriting or installing certain modules you do have a chance that you could break other programs on the system. Luckily Microsoft handles certain important shared dependencies for you so that you as a developer can count on things being there and 'just working'.

I suppose what I am trying to say is, there is a speed and time detriment here with slackware because programs aren't being managed for the distro at hand.

I think that dependency checking is the least important feature of a package management system/distro. It's not difficult nor does it take a lot of time to find out all the neccessary dependencies of a given package, the most time is consumed while compiling things and possibly find an obscure build bug, try to find a patch for it, usually a trivial thing, but still it takes time.
So the thing that matters is just the number of programs that you can just type install_me_that_thing - and it gets installed for you.
Dependency checking can just introduce a lot of trouble into the simple process of installing a package. If you install the package, try the program, see that it doesn't work, install another package,... and so on, you don't loose much time. Where you really loose time, is when compiling all this stuff from source.
I speak this from my personal experience with fedora, debian, mandrake, suse, ... which were all so difficult to manage and I was never satisfied with how things work. The only package management system with dependency resolution that seems to work is portage from Gentoo (mainly due to the *lack* of reverse dependency resolution!) - but thats just my observation of people who have gentoo installed - I really don't want to spend so much time installing my system.
So I "ended" up with Slack, which has a good package manager, no unnecessary dependency resolution, but a smaller pool of packages. This is the *only* downside of Slackware, and the strongest point of gentoo. So, when I have to compile an rather obscure program, I often take a look at what patches gentoo ebuilds apply, this really helps saving time...

At some point you want a distro that you can just "use". That's it, you shouldn't have to fiddle with package this .so that. You just want to install it, start installing some of your applications and just use it. That's it. When you start taking time for a particular package...multiply that by the number of packages. It can add up.

Now in slackwares defense, you shouldn't be installing programs everyday. There is a threshold as to where you are done installing programs and you should be able to just 'use' the programs you installed, however you did them or even how long it took you. What about upgrades? What kind of issues would that introduce that you really don't want to encounter vs. a distro that has the package custom built for that distro anyways? It would just install...where it should be..properly.

Here is my main point. The same reason as to why windows is successful is for the same reason that slackware isn't. I define successful in this case in market shares and desktop preference, even though slackware is a very successful distro flavor of linux bar none. When everyone is experiencing the joys of package management and all the slackheads are still fumbling attempting to install x y and z, it just seems like people are sticking to it for legacy reasons.

Some of you make slackware work in a professional environment and have success, my hats off to you. However, from a business stand point, I am not too sure where superiors are comming from when they can save time ( = money ).

I look at slackware and other distros as tools. Slackware is great for a server. Easy to setup and deploy as a rock solid server. Fedora I use it or even Suse for different reasons, such as development and entertainment. Am I off on those?

Originally posted by KleB:
Of course all of this is subjective and each of us has a different experience. My personal experience of Debian vs Gentoo is that, while both package management systems are equally good, Debian has the advantage in that it doesn't mess with configuration files when you do a global upgrade whereas with Gentoo you have a significant amount of work to do on your config files afterwards.

In fact it was performing etc-update which screwed my Gentoo installation so totally that I gave up on it and moved to Debian. I was a bit upset because it takes quite a long time to get a Gentoo system compiled and configured and I didn't want to start all over again.

Again my experience; Debian is very low maintenance and I'm not clear why you found it difficult to manage. It's true that some of it is a bit peculiar to Debian and I'm still on that particular learning curve.

As for Slackware, I used it happily for eighteen months but an upgrade from v10.0 to 10.2 defeated me. It still remains to be seen what will happen when I dist-upgrade from Sarge to Etch when Etch becomes the stable version.

Naturally, everybody has different taste, and what I didn't like with Debian compared to Slackware is, that you have to configure *everything* yourself. Empty configuration files... At least when I tried it - that's a long time ago, since I'm happy with Slackware now. It may be better now, but I disliked the install program *so* much, it asked for different options for every program you installed. Hey, that's something one should make later himself, not at install time, being unable to access manpages, info, etc. It's confusing for a user. And what I like Slackware for, is simplicity - you really don't have to know much in order to be able to install Slackware. I haven't seen better compromise between features and simplicity in any distro so far.

I also stated quite clearly, that I didn't try Gentoo myself, so I won't judge on how good it's package management is, but I see people around me, who use it trouble-free. And what seems interesting to me, is the "use flags", so you can compile programs with your own options, not just how others thought you like. But, again this is time-consuming and this is the main reason I never tried it myself.

And, please don't get me wrong - my point is, that a package manager with a large repository of programs that you can install, is indeed VERY useful. I miss it with slackware - linuxpackages.net and similar sites on are not official, it happens that packages don't work, and nothing would be wrong if they had more packages at hand... All that I say is, that dependency resolution is the last thing I need with such package manager - if I install 6 programs, or if I install 1 and other 5 get installed automatically, is not a big deal of a difference. Just potential trouble with cyclic dependencies, and similar things. What saves time is the fact that you don't need to run ./configure --some-weird-options &&make &&make install (or, better checkinstall) yourself!

As a conclusion, it seems to me that you really can't have the best of both worlds - control over your system and robustness versus easy and fast program installation.
Slackware currently seems the best compromise for me.

Kernel headers are needed to compile certain third party device drivers like ATi fglrx. Again, you can do as well with the kernel source, but the header-only packages are a lighter download and saves some bandwidth.

See that bothers me. Some of the development decisions in the linux world doesn't please me. I think it would be quite feasible for applications to generate configuration files. When an application gets "unpackaged" or installed...certain files are nescessary in order for it to run. Default configs shouldn't be installed as files in order to run. Sample configs maybe, but not files that could potentially be overwritten. Configurations are a personal preference interface in order for the program to run, not a core component. Maybe this is the philosophy that debian uses.

I have never upgraded from an older distro version to a newer one. Maybe I shouldn't comment on this but I never really liked Operating System upgrades, even for windows. If I get it, I get the full thing. Something must be said for letting a company or a distro to install fresh as if it was "meant to be that way". I just can't get myself to see attempting to preserve information that doesn't no where near take up the amount of importance of what is being upgraded. Clear all sectors and line up every single bit on that drive that was supposed to be for that OS. From a dependency standpoint, either doesn't matter.

KleB, the Debian installer is much improved these days, practically a no-brainer. FWIW I agree with you about the balance in Slackware. It's one reason why so many (myself included) think it's superb.

Originally posted by Kingscriber:
We may be at cross-purposes here. What I'm trying to say is that Debian doesn't overwrite the configuration files that you have generated and doesn't ask you to update them, so that after an upgrade everything is as you left it.

With Gentoo, although it doesn't overwrite those files by default it asks you to update them manually (etc-update). This is where I borked it up. It's very time consuming and not at all straight forward. This is not an anti-Gentoo statement. I still think it's a great distro but you just need so much time on your hands to maintain it. Which is why it's the perfect distro for some Linux hobbyists.

mikieboy:
Possibly.

more clear I suppose as to what you were saying. However I was comming from a standpoint of how those things should operate I suppose. The common cause is enforcing integrity in a efficient updating routine. I think it would be better managed using what I had mentioned while still preserving Gentoo's reputation like you had mentioned.