opkg removes package provider on upgrade

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install package "A" version 2.0 that also provides "B".
2. Create package "B" v1.0 in repository.
3. Create package "A" to v2.1 in repository that no longer provides "B".
4. Do upgrade.

What is the expected output?
Packages "A" v2.1 and "B" v1.0 are installed.

What do you see instead?
Only package "A" v2.1 is installed. Thus provider of "B" is missing.

Original issue reported on code.google.com by KirG...@gmail.com on 6 Feb 2014 at 6:17

[GoogleCodeExporter]

I don't see how opkg can know when you install A that you need a provider of B. 
Does any other package manager (eg. rpm, dpkg) do what you're saying?

Original comment by paul.betafive on 6 Feb 2014 at 10:16

[GoogleCodeExporter]

Oh, I forgot to mention that other packages depends on "B".

Original comment by KirG...@gmail.com on 7 Feb 2014 at 1:39

[GoogleCodeExporter]

So is A being explicitly installed or is it being brought in just to provide B? 
Do any other packages have a direct dependency on A?

I'm trying to get this clear enough that we can write a minimal test case.

Original comment by paul.betafive on 7 Feb 2014 at 3:34

[GoogleCodeExporter]

OK, so there are many packages that depends on A and B from start.
Package A v2.0 is installed from start to provide A and B.

Later separate package B v1.0 is created.
Also updated package A v2.1 is created to provide only A (without B). Also for 
package A new dependency on B is created.

After that update process is started.
After upgrade package A will be upgraded but B won't be installed.
During this process I see following messages:
"Multiple replacers for B, using first one (A)."

Original comment by KirG...@gmail.com on 7 Feb 2014 at 4:09

[GoogleCodeExporter]

So, there are 2 problems which lead to this:

1) The function pkg_installed_and_constraint_satisfied() doesn't check 
pkg->state_want. When pkg->state_want == SW_DEINSTALL, the package is scheduled 
for uninstall and so shouldn't be treated as installed. This is easy to fix.

2) For an abstract_pkg, provided_by is a list of abstract packages, not a list 
of real packages. An abstract package is just a name with no version number. So 
if A 1.0 provides B, A is added to B->provided_by. There is no current 
mechanism to say that a particular version of A provides B but a different 
version of A doesn't provide B. This may be more difficult to fix.

I've added "tests/regress/issue121.py" to master which checks this behaviour. 
It is currently expected to fail on the last check. If you could take a quick 
look at that and ensure it checks what you expect it to that'd be helpful.

I've listed this as Milestone-0.4 as it may be a complicated fix and it seems 
like a rare corner case. I may be wrong though so if you disagree please say so.

The only thing I can't reproduce is the message "Multiple replacers for B, 
using first one (A).". Are any of your packages listed as replacing B?

Original comment by paul.betafive on 16 Feb 2014 at 10:29

• Changed state: Accepted
• Added labels: Milestone-0.4