search

dskvr / opkg

Automatically exported from code.google.com/p/opkg
0 stars 0 forks source link

Upgrade of a package do not upgrade the depends #124

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. package A depends on package B in version 1.0
2. do a upgrade of package B to version 1.1

What is the expected output? What do you see instead?
only package B will be upgraded, but it is necessary that also package A will 
be upgraded to a version that depends on the ne version of package B

What version of the product are you using? On what operating system?
opkg-0.2.1

Original issue reported on code.google.com by muuscl...@gmail.com on 12 Mar 2014 at 10:47

GoogleCodeExporter commented 8 years ago 
I have a further information to this.
If I use in the described case the --force-depends flag, to forth the 
installation of the packages, I get a "corrupt" status file. Then I can find 
some "not-installed" in the status line, and I get some wrong messages if I do 
an "opkg list-upgradable".

Original comment by muuscl...@gmail.com on 29 Jan 2015 at 11:39

GoogleCodeExporter commented 8 years ago 
Yes, there are many issues with current decision mechanism. That's why I've 
started rewriting it to use libsolv library. I'm going to finish it and prepare 
a patch in a week or so.

Original comment by KirG...@gmail.com on 29 Jan 2015 at 12:26

GoogleCodeExporter commented 8 years ago 
KirGeNe: That sounds like an excellent idea.

I've avoided using libsolv myself as it looked rather heavyweight. OpenWRT uses 
opkg on systems with very limited filesystem and RAM size so we do need to be 
careful about size. It looks like OpenWRT are still using r618 though, which 
predates the v0.2.0 release so I'm not sure what's going on there.

We're currently finding new bugs or surprises with dependency resolution every 
couple of months so if libsolv can give us something more stable and 
predictable then I think we're going to have to go for it actually. We don't 
have the manpower on this project to keep solving these bugs with the current 
dependency resolution code in a reasonable timeframe.

This was the same approach I took in adding a dependency on libarchive: the old 
package decompression and extraction code was smaller but completely 
unmaintainable. Better to have opkg be larger but rely on well maintained code.

Original comment by paul.betafive on 30 Jan 2015 at 9:51