Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Understanding unmet dependencies

New to Debian (Or Linux in general)? Ask your questions here!
Post Reply
Message
Author
haidiz
Posts: 5
Joined: 2017-02-19 12:00

Understanding unmet dependencies

#1 Post by haidiz »

Hello all,

I'm new to the debian forum and relatively new to debian itself :) and my first question here is about understanding how to resolve unment dependencies.
I've never had the need before but now I have to install an old version of Apache and PHP in order to conduct some tests.
From my understanding, http://snapshot.debian.org contains packages coming from old snapshots of the repository. I've looked for the package I need, (apache2 for starting) and I included in my source.list.d/source.list the following:

Code: Select all

deb http://snapshot.debian.org/archive/debian/20130304T213347Z/ squeeze main
than I run apt update
and I checked whether I could see the new version with apt-cache madinson apache2, which output shows:

Code: Select all

apache2 | 2.4.10-10+deb8u8 | http://security.debian.org/ jessie/updates/main amd64 Packages
apache2 | 2.4.10-10+deb8u7 | http://ftp.it.debian.org/debian/ jessie/main amd64 Packages
apache2 | 2.2.16-6+squeeze10 | http://snapshot.debian.org/archive/debian/20130304T213347Z/ squeeze/main amd64 Packages
apache2 | 2.4.10-10+deb8u7 | http://ftp.it.debian.org/debian/ jessie/main Sources
apache2 | 2.4.10-10+deb8u8 | http://security.debian.org/ jessie/updates/main Sources
I finally tried to run aptitude install apach2=2.2.16-6+squeeze10 to install the old version and have aptitude resolve dependencies, but I get this:

Code: Select all

The following NEW packages will be installed:
  apache2{b} 
0 packages upgraded, 1 newly installed, 0 to remove and 45 not upgraded.
Need to get 1,398 B of archives. After unpacking 36.9 kB will be used.
The following packages have unmet dependencies:
 apache2 : Depends: apache2-mpm-worker (= 2.2.16-6+squeeze10) but it is not going to be installed. or
                    apache2-mpm-prefork (= 2.2.16-6+squeeze10) but it is not going to be installed. or
                    apache2-mpm-event (= 2.2.16-6+squeeze10) but it is not going to be installed. or
                    apache2-mpm-itk (= 2.2.16-6+squeeze10) but it is not going to be installed.
           Depends: apache2.2-common (= 2.2.16-6+squeeze10) but it is not going to be installed.
The following actions will resolve these dependencies:

     Keep the following packages at their current version:
1)     apache2 [Not Installed]                            

I checked with apt-cache madison all the packages listed above and I can see all of them with version 2.2.16-6+squeeze10, I don't understand why aptitude cannot resolve the dependencies in this case.

Any suggestion on what I'm doing wrong?

EDIT: I forgot to mention that I'm running a fresh install of Debian 8 Jessie without any previous Apache2 installed
Last edited by haidiz on 2017-02-27 19:33, edited 1 time in total.

User avatar
GarryRicketson
Posts: 5644
Joined: 2015-01-20 22:16
Location: Durango, Mexico

Re: Understanding unmet dependencies

#2 Post by GarryRicketson »

I can not begin to guess, since you do not mention what version of Debian you are actually using,...
It would appear maybe you are using Debian 6 squeeze ?
Because that is the "snapshot repo" you used,...
But then again, maybe you are using Debian 8 jessie,.. ?
It appears you also have that in your sources,... ?
Which leads to a suggestion,...read this: https://wiki.debian.org/DontBreakDebian
by haidiz »Any suggestion on what I'm doing wrong?
Trying to mix old and new versions of Debian does not work very well,
and usually does not work at all.
If you want to runs "tests", using Debian 6 (squeeze) and the old snapshot archives, that is fine, but it should be on a separate partition, or VM, it is not very clear what you are trying to do, or why,...
But if you are using Debian 8, Jessie, you definately do not want to be adding
sources to Debian squeeze, snapshot repos,...
Also,
Learn more about doing some searches, it will be of great use to you if you are experimenting and "testing",.. here is a example
Understanding unmet dependencies on a Debian system
Of many hits, this is the one I would start with, (actually that is what I used, when I had some problems with broken packages, and dependencies)
https://wiki.debian.org/DebianPackageManagement

=================
There is a lot to learn, to much to put in 1 post,...but all though you should not try to mix packages from different versions of Debian, and just install them,
just like that,
In some cases, you can safely download the source and re-compile it for the newer or older version, ...do some searches on "how to compile source code for a debian system", something like that.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Understanding unmet dependencies

#3 Post by bw123 »

I don't understand why aptitude cannot resolve the dependencies in this case.
Aptitude probably 'can' resolve the dependencies, but might not be doing this because the current apache2 lists those files as 'conflict's or 'breaks' or 'replaces' would be my guess.
resigned by AI ChatGPT

haidiz
Posts: 5
Joined: 2017-02-19 12:00

Re: Understanding unmet dependencies

#4 Post by haidiz »

@GarryRicketson thank you for your answer. Please forgive my lack of description, I completely forgot to mention that I'm running Debian 8 Jessie (I edited my first post for the sake of completeness).
I'm already running tests on a VM dedicated to this purpose but I was told later that I needed an old version of apache2. Now, I could create another VM, install Debian 6 squeeze and make it run easily (and I will probably do that), but that would take away all the fun of understanding why I cannot install an old version of apache2 in Debian 8. As you suggested, I did some research before posting it here and that is why I decided to make the post, because I couldn't fully understand the results of my findings.

@bw123 this is interesting, in fact I tried something else and if I tell aptitude that I don't accept the solution, it gives me this:

Code: Select all

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

     Install the following packages:                   
1)     apache2-mpm-worker [2.2.16-6+squeeze10 (stable)]
2)     apache2-utils [2.4.10-10+deb8u8 (stable)]       
3)     apache2.2-bin [2.2.16-6+squeeze10 (stable)]     
4)     apache2.2-common [2.2.16-6+squeeze10 (stable)]
So it seems that it can actually resolve the dependencies. I was a bit suspected of that apache2-utils [2.4.10-10+deb8u8 (stable)] but I tried to install it and it broke with:

Code: Select all

Setting up apache2.2-bin (2.2.16-6+squeeze10) ...
dpkg: dependency problems prevent configuration of apache2.2-common:
 apache2.2-common depends on apache2-utils; however:
  Package apache2-utils is not installed.
So here it looks like that apache2-utils [2.4.10-10+deb8u8 (stable)] is the problem and I naively thought "hey, maybe if I keep telling aptitude that I don't like its suggestion, eventually it will solve all the right dependencies".
I stated to answer no ... after no .... until I reached this solution that looked right.

Code: Select all

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

     Install the following packages:                   
1)     apache2-mpm-worker [2.2.16-6+squeeze10 (stable)]
2)     apache2-utils [2.2.16-6+squeeze10 (stable)]     
3)     apache2.2-bin [2.2.16-6+squeeze10 (stable)]     
4)     apache2.2-common [2.2.16-6+squeeze10 (stable)]
I confirmed and ... I got apache 2.2.16-6+squeeze10 running without problem.

I'm a bit confused here, my understanding was that a deb package has meta-data such as Depends, Conflicts, Breaks, Provides which should help in the process of installing a package. When I try apt-cache show apache2 I can see all this info and they all seem "right", in the sense that if tell aptitude that I want version 2.2.16-6+queeze10 all the right info are there in the package.

I don't have another apache2 installed on this system, and apache2 doesn't seem to have any particular conflicts with any packages already installed in a fresh installation of Debian 8, so I really don't understand how come aptitude cannot suggest the right solution right away.

One last thing, please forgive me if this question might sound "ridiculous" to some of you but I found it the best way to understand things even if I sometimes end up asking ridiculous questions :-)

deborah-and-ian
Posts: 182
Joined: 2016-07-13 08:40

Re: Understanding unmet dependencies

#5 Post by deborah-and-ian »

apt can't magically install packages like apache which pull in a complicated network of system libraries from an old Debian release without breakage.
If you want to test old apache releases, you should do so in a VM or at least in a debootstrap. No idea what those are? Google will help.

Also, VM might be the safest choice since you shouldn't be running an old apache version from a deprecated Debian release on a normal system with Internet access.
Debian GNU/Linux 9 Stretch w/Openbox

Acer Aspire E5-521G
AMD A8-6410 APU
4 GB RAM
integrated AMD Mullins
dedicated AMD Hainan Radeon R5 M240 2 GB
240 GB Toshiba Q300 SSD
Realtek RTL8111/8168/8411 ethernet
Qualcomm Atheros QCA9565 wireless

User avatar
GarryRicketson
Posts: 5644
Joined: 2015-01-20 22:16
Location: Durango, Mexico

Re: Understanding unmet dependencies

#6 Post by GarryRicketson »

Your welcome, and no need to apologize, no problem,
That helps explain better about what you are doing,
as deborah-and-ian says , you may have to do a lot of this "manually" , instead
of using apt,...but to be honest, what you are doing is a bit "over" my head,...
I have successfully used a few Debian 7 packages on Debian 6, some things
that were not available for Debian 6, but that would be another topic, and is kind of in reverse , any way good luck.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Understanding unmet dependencies

#7 Post by bw123 »

my understanding was that a deb package has meta-data such as Depends, Conflicts, Breaks, Provides which should help in the process of installing a package
The way I understand it is:

apt keeps a list of 'candidate' versions, so when you tried to install the squeeze version, and it depends on another package with a higher 'candidate' status and version number, which conflicts because the older version needs =2.2, then what is apt supposed to do about it? It hung up instead of hosing your system.

There are a lot of real good apt geniuses on here, so maybe you'll get a better explanation. It's a good topic, never anything wrong with learning a little about apt, IMO.
see /usr/share/aptitude/README
resigned by AI ChatGPT

haidiz
Posts: 5
Joined: 2017-02-19 12:00

Re: Understanding unmet dependencies

#8 Post by haidiz »

Thank deborah-and-ian
deborah-and-ian wrote:apt can't magically install packages like apache which pull in a complicated network of system libraries from an old Debian release without breakage.
I'm referring to aptitude specifically, which according to The Debian Administrator's Handbook and https://wiki.debian.org/Aptitude has a
Score-based and (usually) smarter dependency resolver than apt-get
and in fact, aptitude can resolve the dependencies and successfully install apache ... but not on the first attempt, which I thought was quite strange, but it looks like it's not, assuming I'm correctly interpreting the answers I'm getting :-)
deborah-and-ian wrote:If you want to test old apache releases, you should do so in a VM or at least in a debootstrap. No idea what those are? Google will help.
Didn't know of debootstrap, seems very interesting thanks for the tip.
deborah-and-ian wrote:Also, VM might be the safest choice since you shouldn't be running an old apache version from a deprecated Debian release on a normal system with Internet access.
Yes, as I said I'm already doing it, and is not like I absolutely have to install an old apache on a new Debian. I just tried, and it worked in strange way, so I started to wonder ... no biggie, just curiosity :wink:

User avatar
dasein
Posts: 7680
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Understanding unmet dependencies

#9 Post by dasein »

haidiz wrote:I could create another VM, install Debian 6 squeeze and make it run easily (and I will probably do that), but that would take away all the fun of understanding why I cannot install an old version of apache2 in Debian 8.
No one here is trying to discourage you from learning. In fact, we encourage it.

But the VM idea doesn't preclude you from using Jessie. In fact, since you're new and seemingly eager to bork your system, maybe strongly consider using a VM as your primary workspace. Those one-click "snapshots" are just too handy for when you try something "fun" that turns out to be "destructive."

And yes, to be extra clear, I'm talking about running a Jessie VM atop a Jessie base. Do all your experimenting in the VM and leave the host system alone. (Unless reinstalling is something else you consider to be "fun.")

But your current course, mucking round blindly with your base install, is risky and will bite you in the butt eventually. (See http://forums.debian.net/viewtopic.php?&t=114130 for details)

If you're determined to mess your base install (or frankly, even if you're not), make regular and frequent backups.

User avatar
GarryRicketson
Posts: 5644
Joined: 2015-01-20 22:16
Location: Durango, Mexico

Re: Understanding unmet dependencies

#10 Post by GarryRicketson »

I do not have Debian 8 (jessie) installed on any "bare metal" machines,
but do run it on VM's, one on the Debian 6 powered machine, also on the Debian 7 , ( my main desktop computer), I have Debian 8 on a VM, it works ok, however
it is very prone to crashes, on both, VM's, which leads to why I have never installed it to anything I need to depend on.
But also, similar to the OP, since I have been experimenting, and sometimes
also here, I need to run Debian 8,...to see if I can duplicate a problem, etc,...
Unlike the OP, I have not started trying any server , not even a localhost on any
of the VMs with Debian 8, so I can't say much about trying a old version of Apache2
on,... I suppose I could give it a try, but the interest is not really there.
In any event, the point is, it works pretty good to run Debian 8 on a VM, even on older versions of Debian,..
Don't get me wrong, Debian 8 may be stable enough as a "bare metal" system, as long as you don't start "mucking round blindly with your base install,", as Dasein says,... So that is the main point, it really would be best to use a VM and install Debian 8 to it, then you can safely start experimenting, you can even use
the real HD as the source for the install on the VM, so it is exactly the same as what you have as the host.
Sorry, if this has kind of gone into another topic,...
Also, using a VM works fine,for testing and experimenting with other aspects of a server, as well as different versions of apache2 and mysql,... I have a mirror/clone of my online server on a VM, Debian 7.00 is the host, the server is actually Debian 7.6

haidiz
Posts: 5
Joined: 2017-02-19 12:00

Re: Understanding unmet dependencies

#11 Post by haidiz »

Thank you guys for all the answers but I feel like we're going a little bit off-topic here.
When I said I'm "relatively new" to Debian probably I was misleading, sorry.
I din't mean to say I'm new to computer science :-) I meant to say that I've used Debian before but I notice I didn't really understand a lot of things related on how Debian works. So now I've decided to "go back to the basics" ... but not too much :-P

I understand the risky business on experimenting outside of a VM, in fact I'm absolutely NOT doing it, and I've never said I'm doing it :-)
My host system is a macOS and I've some VMs which only existing purpose is doing various tests and this all thing is just a coincidence: I put on a Debian 8 and then I was told I needed an old version of apache, so I said "ok let's see if I can put it here anyway".

Back to my question, aptitude IS able to correctly install apache coming from the squeeze repo into a Debian 8 system, but at first it seems reluctant in doing so.
From what I'm understanding, mixing-up Debian packages from different versions of Debian is really bad and not the "Debian way of doing things". Because of this (rephrasing bw123 suggestion) aptitude CAN do it (since I eventually managed to do it), but it's reluctant in doing it at first because it recognises that I'm installing an old version of a package in a newer system that has a newer version of that package and "that's not the Debian way of doing things".
So basically aptitude is trying to protect the system from my attempt in forcing to install an old package when a new one is available.
Am I getting this right? :-)

Thanks @dasein, the link you provided seems very interesting, I'll give it a look ASAP.
dasein wrote: But your current course, mucking round blindly with your base install, is risky and will bite you in the butt eventually. (See viewtopic.php?&t=114130 for details)

User avatar
pylkko
Posts: 1802
Joined: 2014-11-06 19:02

Re: Understanding unmet dependencies

#12 Post by pylkko »

One way to think about it is that every release (every new stable) is a collection of packages that have been designed to work together, testing and patching as needed (this is done to the extent that it is possible by hundreds of people). Other "home made" combinations may or may not work. It is unknown territory. Just because this worked here with apache in this case does not in itself guarantee that it would always work with any given package or mix. Also, if you have mixture and you latter on upgrade some packages with new conf files or whatever, there is always the risk that something will just break and that it might be really hard to diagnose as you are the only one in the world with that combination of packages. If you keep this in mind and are mindful of what you are doing, it might not be a problem. Yet, experience shows that many many people have broken their systems beyond repair (the link).

deborah-and-ian
Posts: 182
Joined: 2016-07-13 08:40

Re: Understanding unmet dependencies

#13 Post by deborah-and-ian »

aptitude never sat right with me. I think it can do what you want, but it has to "learn" it. Or at least that's how I understood the way it works. Somewhat like a heuristic approach. But that's also why I don't trust it, because I've had e.g. the following example:

1. I install a task or meta package to get Gnome
2. I didn't like Gnome, so I removed it with apt-get and installed Xfce
3. I run aptitude to install package foo and it wants to reinstall Gnome.

So, while I guess it's starting to learn about my system and get what I had earlier in order to "fix" whatever task was installed, that's not actually what I need and I lose a lot of time. It's unpredictable behaviour, or maybe just unpredictable to me because I've never bothered to read the aptitude manual. Hence me preferring to do things more manually with apt-get.

In your case (I'm assuming it's something like: I need version 1 of something, but version 2 is installed and installing version 1 would break a lot of stuff), I'd rather have a fool proof base system and then install individual debootstraps for the strange versions. Or if you're using Sid or Testing, you can pull in a lot of stuff with flatpak or snap. This is quicker, but I guess doesn't really satisfy the curiosity you have. :D
Debian GNU/Linux 9 Stretch w/Openbox

Acer Aspire E5-521G
AMD A8-6410 APU
4 GB RAM
integrated AMD Mullins
dedicated AMD Hainan Radeon R5 M240 2 GB
240 GB Toshiba Q300 SSD
Realtek RTL8111/8168/8411 ethernet
Qualcomm Atheros QCA9565 wireless

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Understanding unmet dependencies

#14 Post by bw123 »

... aptitude is trying to protect the system from my attempt in forcing to install an old package when a new one is available.
Am I getting this right? :-)
I don't think aptitude is that smart, but the effect you suffered is a good proof of concept. The real credit goes to debian's APT system, which is one of the reasons debian is a very robust distribution. APT is "the core of Debian namely its package management."

https://wiki.debian.org/Apt

I do agree that aptitude has a lot of quirks, and does seem to 'learn' things is a haphazard way. I use it exclusively, because I'm old-fashioned, and like the ncurses interface. if you try to mix it with apt-get or other package management tools, it might try to over rule them. It does not have super cow powers.
http://www.eeggs.com/items/37085.html
resigned by AI ChatGPT

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Understanding unmet dependencies

#15 Post by stevepusser »

For the most part, program libraries try to be backwards compatible, so you seem to have lucked out with that particular set. It's naturally much harder to have them be forwards compatible, which is why most borked installs we see are from adding testing or unstable repositories to stable to get Shiny New Stuff.
MX Linux packager and developer

haidiz
Posts: 5
Joined: 2017-02-19 12:00

Re: Understanding unmet dependencies

#16 Post by haidiz »

Thank you everyone for the suggestions, I appreciate it :)
I was reading the aptitude manual and I think I found the description of this behaviour.
Little recap, aptitude doesn't suggest the "right" packages dependency solution as a first choice (you need to tell him couple of NOs before getting to right combination) when trying to install an old version of a package (apache in this case) coming from a snapshot repository of an older Debian release.

According to the manual, aptitude has two algorithms for resolving dependencies. The manual labels these algorithms as "immediate resolution" and "interactive resolution". http://aptitude.alioth.debian.org/doc/e ... 03s01.html
The first algorithm ("immediate resolution")
It is invoked whenever you select a package for installation interactively, and immediately after one or more packages are marked for installation at the command-line. Immediate resolution is fast and will solve most dependency problems, but it is sometimes unable to find any solution.


while the second one ("interactive resolution")
is invoked when packages have broken dependencies even after immediate resolution[11]. It can resolve more dependencies, it allows you to review a solution before applying it, and it allows you to provide feedback to the resolver, guiding it towards a better solution.
In the manuale here http://aptitude.alioth.debian.org/doc/e ... 03s02.html it also says about the "immediate resolution" algorithm:
A dependency might not be satisfiable due to version restrictions and due to the limitation that only candidate versions are considered. For instance, say that versions 1.0 and 2.0 of fileutils are available, that the candidate version is 1.0, and that the package octopus declares a dependency “Depends: fileutils (>= 2.0)”. Immediate resolution is unable to resolve this dependency: it will never consider version 2.0 of the package, since that is not the candidate version.
with apt-cache policy I checked the candidate versions of apache and its dependencies and the candidate versions (obviously) are 2.4.10-10+deb8u8.

So I guess that must be it.
If I'm not misunderstanding the manual, aptitude (just like it happens with apt-get) executes the "immediate resolution" first, which never takes into consideration the possibility of installing a version different from the candidate one.
When you don't accept the solution, it falls back on the "interactive resolution" which (I'm guessing here) tries to resolve the dependencies but still prefers to install the candidate versions if possible. That's why you need to give him a couple of NOs before he finally decides to select the old version of all the dependencies.

It seems to follow the behaviour described in the manual.

Post Reply