Hello, ...

I have the following problem with one of my packages :

ocaml-base provides ocaml-base-3.06
liblablgl-ocaml depends on ocaml-base-3.06

both of these are installed.

Now i modified ocaml-base, and changed the provide to ocaml-base-3.06-1.

if i install ocaml-base on a clean box, and try to install
liblablgl-ocaml it will complain that ocaml-base-3.06 is not installed
and refuse to install.

Now if i use a box with ocaml-base and liblablgl-ocaml already
installed, and install the new ocaml-base (upgrading it), i was
expecting dpkg to complain that the old ocaml-base provided
ocaml-base-3.06 which is needed by liblablgl-ocaml, and the new
ocaml-base is no more providing it.

This did not happen, the new ocaml-base installed cleanly, and broke all
existing ocaml bytecode packages as well as my ocaml building
environment.

Friendly,

Sven Luther

Hello ...

I reported this bug 14 days ago, but don't even got an answer.

Do you think there is a solution to this problem, are you too busy to
work on it or something such. Or do you simply think this is a stupid
bug report and are ignoring it ?

If you are busy, it would have been nice to tell us, since we are
holding up a major change in the whole pool of ocaml packages because of
this.

Also, if you have no time to fix this, or even to consider it, i may
look into this myself (altough a few pointers to where to start would
be fine), not that i have much time, but i think it is important.

Note that apt knows how to handle this correctly, and when installing
(as opposed to upgrading) a package, this does not occur.

So i guess dpkg needs only to check when upgrading a package that a
needed virtual depends was in the old package and not in the new one. It
should not be too difficult, unless dpkg is severly misdesigned, which i
think it is not.

BTW, is this related to the versionned virtual dependency bug ?

Friendly,

Sven Luther

I was tempted to merge #217862 and #170825 but I can't be sure
that they report the same bug since the former involves a
normal dependency and the latter involves a dependency on a
virtual package.  However, the submitters of these bugs may
be interested to compare notes.

version of a package still satisfies the dependences that have been
satisfied by the old varsion of the same package.

Here's my attempt at getting this one fixed.  Unfortunately I can't
claim to have any deep understanding of dpkg's workings after what
perusing I did, but it still seems to fix this.  At least it fixed the
test case shown.

This'll still need at least some refactoring.  The error message
handling is pretty much identical with the code prior to my code,
those could be merged and moved to their own function.  Also, the
error message generated is a bit off.

If nothing else, then the apparent simplicity of the patch bothers
me...  I hope it's of any use.

Hello,

the patch caused the following Error:

dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry <= 4' failed.
E: Sub-process /usr/bin/dpkg exited unexpectedly

Tried with patched dpkg 1.10.28 and 1.13.10

Kind regards,

Henry

How did you run dpkg?  What was the command line?

At least I didn't get that error with the test cases I ran on the patched dpkg.

Hello

apt-get install [somepackage]

Like I said, I got it in all cases, both with 1.10.28 and 1.13.10.
What compiler did you use? I still use gcc 3.3.5 here.


I attach an strace from  dpkg --configure -a


Regards,
Henry

For simplicity I'll call the package to be configured with A.

My last patch failed to take into account the scenario where other
packages depended on A where there were no version mismatches.  Only
the case where there would have been a version mismatch after the
configure was checked for.

The check for dependencies after the install would see that A's state
is unpacked, what would cause deppossi_ok_found to return as status
deferred.  But since we don't test for A's dependencies here but the
packages that depend on A instead we don't care of that information.
Hence we can just leave the status as ok even if the check returns
deferred.

I must confess that I still don't understand the full implications of
this patch.  But hopefully this is nearer to a correct fix already.

Hello.

I'd like to receive some comments about my patch to #170825 and
possibly have it merged.  Currently a package upgrade can invalidate a
dependency satisfied by the old version of the package but not the new
one.  I've added a check to catch this situation.

My AM asked to be CCd.

Hello Kari,

I tried your patch sent to #170825.

I think it deals with 217862 and 270545.

I'm not sure it fixes 20471 (I'm not sure I tried the right sequence).
And it does not deal with the use case described at the beginning of
#170825.

170825 is about a virtual package:
A_1 Provides: A-1
A_2 Provides: A-2
C Depends: A-1

The sequence:
        dpkg -i A_1
        dpkg -i C
        dpkg -i A_2
should fail when installing A_2

(In this case, A_2 has no pkg->installed.depended, so your code is not
even executed)

I'm attaching equivs control files in case you want to build packages for
testing (build them with equivs-build <control_file>).

In your patch, you should also change the internerr message (in case a user
fall there, it may be interresting to have a message different from the
previous one).

Also, I don't understand the "deferred installs do not apply here".
We are going into this code path when --force-depends is used.

Thanks for taking care of this bug anyway.
I will run with this patch, and will inform you if I find any side effect.

Kind Regards,

Hello Kari,

So, I ran with your patch.

I experienced a failure (well, at least a behavior change; I've not
investigated deeply; maybe it's a bug in the packages dependencies, which
is unoticed without the patch)

I failed to upgrade exim4 (exim4, exim4-base, exim4-daemon-light, exim4-config)
from 4.61-1 to 4.62-1 with this patch applied (and succeeded without it).

I'm attaching more information in case somebody wants to reproduce this
failure.

I will investigate more later (and will try to make small packages to ease
reproducing it in the future).


I also experienced another failure while updating gcc-4.1 (I've not yet
checked if it's the same issue).

Kind Regards,

tags 170825 - patch
severity 170825 normal
thanks

I have checked the supposed patch for this bug, which is in #170825,
and I'm afraid it's not right at all.  It changes dependencies_ok in
packages.c which is used during configure and remove.  What is needed
is to enhance the checks which happen before unpack.

I'll prepare a replacement patch.

Ian.