arstechnica.com
Then you get a problem where you try to install something really simple like the jdee extension for emacs and you get this:
Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:
The following packages have unmet dependencies. jde : Depends: cedet-contrib (>= 1:1.0pre4-2) but it is not installable Depends: cogre (>= 1:1.0pre4-2) but it is not installable Depends: eieio (>= 1:1.0pre4-2) but it is not installable Depends: semantic (>= 1:1.0pre4-2) but it is not installable Depends: speedbar (>= 1:1.0pre4-2) but it is not installable Recommends: ecb but it is not going to be installed E: Broken packages
Wow great, what the hell are these packages and why the hell are they not installable? It gives me absolutely no clues whatsoever so your only options are:
A) Google the error and hope that somebody has exactly the same problem with exactly the same version of the distro you are using.
B) Try and compile everything from source which about 50% of the time will generate even more cryptic error messages or ask you questions you have no idea of the answer to like asking for the locations of obscure libraries and even when it does work,it will take the software outside the cozy world of apt-get management and may require you to install different versions of dependency libraries all over your home folder.
C) Completely give up on the idea of installing that software.
incidentally if anyone has a solution to this particular problem with jdee I'd love to know :)
I don't understand how these conflicts come into existence in the first place, surely if two programs require different versions of the same library to run it should be possible to somehow install both versions and link each program to a different one?
I didn't realize how angry JDEE made me. Two years passed since I tried to use it and that package can still bring out some latent rage.
Is it worse than say eclipse?
I think JDEE suffers from being too large with too many dependencies. Emacs configurations make almost every install unique and I think the maintainers of emacs projects in general have a hard time supporting users because people generally stop writing documentation when "It works for me." The same way you find your keys in the last place you look.
For instance http://jdee.sourceforge.net/install.html
Download the latest versions of Eric Ludlam's speedbar, eieio, and semantic bovinator packages and install them on your system, each in their own directory.
You can download these packages from SourceForge.
Note Emacs and XEmacs include earlier versions of speedbar that are incompatible with the JDEE. You must delete the earlier version or ensure that it is not on the Emacs load path. Otherwise you will get a Lisp error when trying to start Emacs.
That documentation might have made sense at the time. but I'm currently using emacs 23.3.1. Is my version of speedbar still out of date? Do I have to downgrade it? Upgrade it?
http://cedet.sourceforge.net/ The cedet page for getting those "newer" packages only provides download links to the entire cedet package. And without version references in the documentation how can I tell if my debian installed version might be good enough?
Shameless self-promotion ... over the past year, I've been working on a project that aims to solve this dependency hell problem: http://www.stanford.edu/~pgbovine/cde.html
All you need to do is find a distro where jdee works, package it up with CDE, and then transport it to your own machine. email me if you have questions.
Does seem like quite a drastic solution to this problem though.
So you are using ptrace to intercept system calls and then copying files that are used. I suppose the problem with this is that when you are running CDE to generate the dependency list it is down to what is actually used, so if you don't hit every piece of code in the program when doing the "generation" part you may not get a completely working package.
I suppose you can do some evaluation on the binary to figure out which calls it might make during execution but this wouldn't work to well if the software in question is built using something dynamic like python where library calls may not necessarily be the same so cannot be predicted in advance?
0) I think problems like this are often fixable if you are an APT wizard, which I am not. But sometimes a look at the Debian docs makes an inscrutable error scrutable. I also usually get more helpful (and current) advice on the debian-users list than search engines turn up. [1]
1) I run Debian stable. I think errors like this are fairly common on unstable and mixed systems; I don't know how common they are on Ubuntu. But I believe I have never run into a problem like this on the stable release.
2) If trying to compile everything from source, the deb tools can help a lot, too (apt-get source, apt-get build-dep). It's only if you get to the point of downloading a source tarball from a third party that you have to completely leave the cozy world of APT. (And even then, I find I have better luck than on other platforms, because I can still use APT to install dependencies. No such luck on, say, OS X, at least not without a third party package tool.)
[1] See http://lists.debian.org/search.html to search the list archives.
I've tried asking on mailing lists in the past (admittedly a long time ago) but generally find that I often get no answer or an answer which asks all kind of questions I don't know the answer too.
I've used build-dep stuff before , but I sometimes find that build-dep breaks when the packages break.
What I find odd is that complex stuff like kernel/driver/server upgrades usually go without a hitch and I only tend to get these problems with stuff like jdee (which is basically just a text editor plugin).
This is a big problem with Linux , debian based distros in particular. There is always a sense of "If you want A you should use distro X , if you want B you should use distro Y". When A and B are often just sides of the same coin and should not be mutually exclusive.
I don't feel that this is at all an artifact of distribution niches. Rather, this is a universal phenomenon of software engineering: every change (including bugfixes!) tends to introduce bugs. While bugfix changes usually (though, as many readers will know, not always) reduce the total bugginess of your product, most other changes tend to increase bugginess. So there's an inherent trade-off between on the one hand having a short development cycle, a good (for some definition of good) feature set and quick latency between the design and implementation stages, all of which can be used to make a product more user-friendly; and on the other hand having no bugs, which is also a big contributer to user-friendliness.
tl;dr: Ubuntu's customized design and up-to-date packages are not orthogonal to its bugginess; Debian's years-long testing and integration process is not orthogonal to its years-old package selection.
If I have a problem with my Linux Mint install and find something related to fixing the problem in Debian there is a fair chance it will work, but then again there's a chance it doesn't. If the solution is written by a slackware user the chance that it will help is even smaller.
Lack of bugs and issues is a huge part of the overall user experience. There seems to be a belief that making a shiny product that looks like something from apple will make it more friendly to users, this is fallacious.
I think the original reason that the mac was perceived as being more user friendly was only partly down to it's UI and mainly down to the fact that Apple had a simpler and more focused idea about how their product should work and what it should do (controlling the hardware helps somewhat here) and therefor there was just less surface area for bugs.
Linux has the problem of being a patchwork of software with different levels of quality put together by different people with different ideas about how things should be. Whilst this has it's merits it does lead to some problems which really have no right to be real problems.
[ETA] Found it: http://www.box.com/s/m0nkpxszhnccls210coe