debian dependecy hell

Anton Markov anton-F0u+EriZ6ihBDgjK7y7TUQ at
Sat Jul 31 17:07:20 UTC 2004

Hash: SHA1

Peter L. Peres wrote:
> But I did not do that at all. All libs were fetched from the internet
> via apt-get install. Unfortunately I do not have a Debian cd here so I
> tried to d/l as little as possible.
Libs are probably the hardest to upgrade, because other packages may
depend on a particular version of the library. If you upgrade the
libraries without upgrading all packages that depend on these libraries,
than APT will be very upset, but it will respect you decision to install
 the libraries (that's why it says, "but version x.y.z will be
installed"). Instead, it will remove the other conflicting packages.

> My source package requires some modern libraries, from testing/unstable.
> The system itself says it is testing/unstable. More of the latter
> apparently ;-) But again, *I* pushed the button.
Remember, unstable and even testing receive regular updates daily. It's
not unsusual for your system to become out-of-date.

If you really need a newer version of some library, but don't want to
update your entire system, it's best to compile/install the library into
*/usr/local*. The package manager will never touch it, and it will not
effect any packages already installed.

> I did not install *any* random stuff. The way I understand it, I
> forcibly updated a library on which kde depends and the apt system then
> tried to update the entirety of kde (but it did not ask for upgrade, it
> asked whether to remove the packages, and *I* said yes - my mistake ?).
It is best to never *force* any package to install/update. The APT
system is designed in such a way that all installed packages *always*
have their required dependancies. Therefore, if it can't satisfy a
package's requirements, it deletes it rather than leaving it
unconfigured. Fortunately, it always asks before uninstalling stuff. If
you run into the situation were you *upgraded* a library and APT is not
happy about it. It is best to once again forcibly *downgrade* it back to
the previous version. Then find some alternate way, such as compiling
the lib from a tar.gz file.

As for your KDE trouble, if you can get your hands on a Debian CD(s)
(preferably the same release (stable/testing) and your system (I am
still not sure if you are running "stable" or "testing"), then "apt-get
install kde" or "apt-get install <separate KDE components>" will have
you up and running in no time.

> I expect the distribution to be somewhat tolerant of people doing
> non-standard things with it. F.ex. I ran Suse for a few years and it had
> its package manager, and it did its thing, and I had my development
> stuff, which I managed using tar.gz files, and we were happy together.
> Suse yast would even refrain from overwriting config files which I
> edited and tell me about it at each update/config run. I never had a
> problem of this kind with yast (like adding my own devel library to the
> system and it trying to tear down everything because of it).
Debian is very tolarent of user changes. It never EVER touches anything
in /usr/local, and that means that you can keep any version of any
library in /usr/local. As long as you don't do something that will break
existing installed packages (such as *replacing* old libs with new
version that the packages weren't designed for), then the package
manager won't bug you.

Also, apt-get ALWAYS asks you whether or not you want to replace a
configuration file with the one provided in a package if it detects that
the file was modified since installation. It also give you the option of
viewing a DIFF of the two files.

Debian is really easy to get along with. As long as you leave the
package manager (meaning all files in /usr/lib, /usr/share, /usr/bin,
etc.) alone to do it's job of installing packages and solving their
dependancies, and putting everything either in your personal directory
or /usr/local, everything will be fine. For example, I have the
Debian/unstable version of XFCE4 in /usr and a recent CVS version in
/usr/local. They co-exist just fine.

- --
Anton Markov <("anton" + "@" + "truxtar" + "." + "com")>

GnuPG Key fingerprint =
5546 A6E2 1FFB 9BB8 15C3  CE34 46B7 8D93 3AD1 44B4

Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

The Toronto Linux Users Group.      Meetings:
TLUG requests: Linux topics, No HTML, wrap text below 80 columns

More information about the Legacy mailing list