Removed dependencies not marked as orphaned during upgrade

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create Packages.gz containing:

   Package: bar
   Version: 1.0.0
   ...
   Depends:

   Package: foo
   Version: 0.0.1
   ...
   Depends: bar (=1.0.0)

   Package: foo
   Version: 0.0.2
   ...
   Depends:

2. Install foo-0.0.1
   - cd /tmp/opkg
   - wget http://repo/foo-0.0.1.ipk
   - opkg update && opkg install --force-downgrade foo-0.0.1.ipk

3. Confirm installed packages
   - opkg list-installed
     > foo-0.0.1
     > bar-1.0.0

4. Upgrade foo-0.0.1 to foo-0.0.2
   - opkg update && opkg --autoremove upgrade

5. Confirm installed packages
   - opkg list-installed
     > foo-0.0.2
     > bar-1.0.0

What is the expected output? What do you see instead?
The expected output for step 5 would be:
  - opkg list-installed
    > foo-0.0.2

During the upgrade process opkg outputs the following:
"pkg_remove_orphan_dependent: bar was autoinstalled and is still required by 1 
installed packages."

What version of the product are you using? On what operating system?
opkg 0.2.0 on Linux 3.12.0-xilinx arm v7

Please provide any additional information below.

One particularly nasty workaround is to make the new foo package act as a 
replacement for bar:

   Package: bar
   Version: 1.0.0
   ...
   Depends:
   Provides: bar
   Conflicts: bar
   Replaces: bar

   Package: foo
   Version: 0.0.1
   ...
   Depends: bar (=1.0.0)

   Package: foo
   Version: 0.0.2
   ...
   Depends:
   Provides: bar
   Conflicts: bar
   Replaces: bar

As long as the bar package appears before the foo package in the index then 
downgrades and upgrades work as expected. opkg will use the first replacer it 
finds. I would prefer to use a postinst script however I cannot do an 'opkg 
remove' whilst opkg is running as it is locked.

Original issue reported on code.google.com by seo...@gmail.com on 7 Aug 2014 at 12:52

[GoogleCodeExporter]

As I said in email, it looks like, during an upgrade, opkg is
checking for orphan packages before the old package is marked as uninstalled.

I was wrong thinking that was the problem though, pkg_remove_orphan_dependent 
gets the number of installed dependents of each autoinstalled package and then 
subtracts one to account for the old package which is about to be removed. It 
may be double counting dependencies though.

Original comment by paul.betafive on 25 Aug 2014 at 12:44

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

[GoogleCodeExporter]

I'm pretty sure this is now fixed in both the opkg-0.2.x and master branches. I 
managed to locally reproduce your issue and made some changes to 
pkg_remove_orphan_dependent until the autoremove went ahead as expected.

I'm going to assume this is now fixed. If it isn't just add a comment and we 
can re-open this.

Original comment by paul.betafive on 28 Oct 2014 at 11:38

• Changed state: Fixed