> It is a missing dependency problem. > > | and how do I get > | apt-get/dpkg/dselect/whoever to cough up the facts of the case? > > It did! :-). (see the end of the long apt message where it talks > about unmet dependencies)
Well, yes and no. It's implying that somehow its inability to resolve the dependency issue is a *bug*, which apparently isn't true... > The situation arises from using apt preferences - you set 'stable' as > the default release, however you explicitly requested a 'testing' > package. apt will not, by default, with those settings upgrade the > libraries to the necessary versions. Instead it picks the 'stable' > version, by default, and then complains that it is too old. Okay... I didn't go through this earlier, or detail it in my answer to the other respondent, but: By various manipulations of the "preferences" file, and command line options to "apt-get", it is possible to get it to go off and actually try to do the installation. But, while the problem apparently *is*, in this case - just as you say - that it is constrained to packages that are too old (the stable version of "firestarter" is already installed on my system, so - if I now understand this correctly - what apt-get is complaining about is that it is being forced to use *support packages* that are too old, and doesn't know what to do about it, to the point where it thinks there's a bug somewhere. > There are a few ways to solve that. > 1) temporarily change the default release > # apt-get -t testing install firestarter > (or edit /etc/apt/preferences) I did that. It *is* possible to force "apt-get" to come up with a (stupendous) list of packages required to get the "testing" release. But because going down that path caused me to fall in quicksand, I decided to open the discussion with the issue of "apt-get" claiming that it had a bug... > 2) explicitly specify which release or version you want the packages > from : > # apt-get install firestarter libbonoboui2-0/testing > libgnome2-0/testing libgnomeui-0/testing I did that also, but only per "apt-get install firestarter/testing". I didn't try it on the individual packages it was complaining about all on one command line. However, in general it appears that there are various combinations of sources.list and preference file contents and command line syntax which will *force* apt-get to compute an entire package download configuration to ostensibly solve the problem (not that I trust its judgement one iota, mind you...) > Option #1 is ok. Option #2 will soon get tiresome as you iterate > through each layer of dependencies. (once you run the above command > you'll find out what newer libraries those libraries need and so on) > Aptitude's curses interface makes option #2 easier. It also gives a > clearer indication of what was wrong in the first place. I did, at one point, end up descending layers of dependencies by successive iteration of something. (It was late at night, or early in the morning, so "something" will have to suffice as an explanation of whatever it was I was doing...). That was the point at which I started realizing that I was fishing in *really* deep water and probably really looking at an upgrade to "sarge" before I was done. > In general you can't. You need to decide whether or not you are > willing to attempt the upgrade and see what happens. I can tell you > that the libraries in testing will need a newer libc6 than stable has, > and once you upgrade libc6 (and gnome) you will have upgraded almost > everything to testing and you won't have a 'stable' system any more. > There is nothing inherently wrong with that, unless you really want to > stick with stable. If you really don't want to move to testing, then > you will probably find it easier to find a backport of the app and all > dependent libraries or install the source package and build it > yourself. Okay, you've really nailed it there. I was thinking of starting with a "libc6" upgrade as a first step to solving the problem, since in the process of examining the entrails I realized that *a lot* of the broken dependencies would be resolved by getting the libc6 package. But - as both you and the other respondent have said - I suspected that doing so would (a) probably break a lot of things, and (b) even if it worked, put me a good distance of the way to a "sarge" installation anyway. If I'm going down that path, I'll just install "sarge" on another bootable partition where I can perform unnatural acts on it without jeopardizing my "stable" installation. > | (I've already tried > | various things, and APT is *really* tenacious about not liking the > | idea of installing this - and I already tried an "experiment" > | in loading the "libbonoboui2-0" package which nearly ended in > | disaster; see my earlier post today) > > This is probably due to the chain of dependencies and your setting > stable as the default release. Actually, I think the previous respondent's more general comment, that mixing "testing" packages with a "stable" installation is a recipe for a broken system, is probably accurate in this case. If my current undersatanding is correct, even when I overrode the designation of "stable", I still was going to end up with such a huge pile of incompatible packages that something was almost guaranteed to break. > | so why can't I find *anything* about either the "apt-get" error > | message generally > > I don't know. I do know that 'apt-get' was created only as a > proof-of-concept interface for testing the "apt" system/library. It > was never intended to be used as widly as it is. Instead admins are > supposed to use nice frontends like aptitude (or others). Having said > that, I will admit to having used apt-get directly for a long time > before really giving aptitude a chance. What documentation I found and read, in the package installation, apt, upgrading, and "howtos" that I wandered through, only described "apt-get" and "apt-cache", as I recall (along with "dpkg" and "dselect". "aptitude" did not install by default with stable Woody, at least. > | (3) Is it possible that I need to do a complete upgrade to the "sarge" > | Kernel, in order to get this new "firestarter" to work, > > Yeah, basically. > > | and if so how do I make that determination > > Trace the dependency chain and see how many packages need to be > upgraded to satisfy all deps. In this case it will (almost certainly) > require a new libc6. There's no question about that. Now: (1) Are you implying that if the libc6 package needs to be upgraded to a "testing" version, that upgrade is of a comparable magnitude to upgrading the entire install to "sarge"? (2) (and I asked this in my reply to the other respondent...) Are there multiple versions of libc6 (or other packages) within a given release, and if so, do I need to determine how many of them cross a "release boundary" to figure out whether I'd actually be "wandering" into another release? Once again, as I mentioned in my previous reply, I've apparently missed some documentation that explicitly answers my last question, above, with respect to versions, releases, and what can be safely mixed in upgrading... probably, if I'd known all that, I'd be spending far less of my own and others' bandwidth on this. So I'm interested in finding the documentation, and figuring out how I managed to overlook it. Thanks very much, for your help (and the same to the other person who responded; I've sort of composed both of these replies at once). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
