Upgrade of a package do not upgrade the depends

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'm not clear what the problem is from your description. What are the exact 
dependencies of A. If it's just "B" then I don't see anything wrong here.

Original comment by paul.betafive on 13 Mar 2014 at 12:56

GoogleCodeExporter commented 8 years ago

I will explain it in a longer example.
The control file of package A contain this lines:
Package: A
Depends: B (= 1.0)

The package B contain this lines:
Package: B
Version: 1.0

The new package B looks like this:
Package: B
Version: 1.1

If I now make an upgrade of package B to version 1.1 the dependencies of 
package A are no longer fulfilled. I would expected that in this case, also the 
package A would be automatically upgraded to a newer version, thats control 
file looks like this:
Package: A
Depends: B (= 1.1)

But an "opkg-cl upgrade B" does not do so. After the upgrade of package B I 
have a not fulfilled dependency in package A.

PS.: Can you please correct the headline of this issue. I wrote "Uograde" 
instead of "Upgrade"

Original comment by muuscl...@gmail.com on 13 Mar 2014 at 3:31

GoogleCodeExporter commented 8 years ago

I assume the two versions of package A have different version numbers, with 
latter one (which depends on B 1.1) having a higher version number than the 
first (which depends on B 1.0).

This does sound like a bug but I disagree on the correct operation. I don't 
think 'opkg upgrade B' should upgrade A unless A is a dependency of B. I think 
instead it should error out saying that the upgrade of B is blocked by A. The 
user should then be able to run 'opkg upgrade A' which should upgrade B as well 
as it is a dependency of A. How does that sound to you?

Original comment by paul.betafive on 13 Mar 2014 at 5:26

Changed title: Upgrade of a package do not upgrade the depends
Changed state: Accepted

GoogleCodeExporter commented 8 years ago

You are right. That sound like a good way!

But now I have a second problem, that maybe is the same issue. If I install a 
new third package C, that depends on B version 1.1, than package B will be 
upgraded to version 1.1, but package A stay on version and has a not fulfilled 
dependency after that, e.g.:

Install package C:
Package: C
Depends: B (= 1.1)

This also upgrade package B to:
Package: B
Version: 1.1

But it not upgrade package A, this stay on the old version:
Package: A
Depends: B (= 1.0)

That brakes package A since the dependencies are no longer fulfilled.

Original comment by muuscl...@gmail.com on 13 Mar 2014 at 6:58

GoogleCodeExporter commented 8 years ago

If we block B from being upgraded it should in turn block C from being 
installed (as it will not be able to satisfy "B (= 1.1)").

I think the next stage is to throw together a test case for this. I'm fairly 
busy but I should get to it soon, give me a reminder if I haven't within about 
2 weeks.

I'm guessing that the problem itself is in the function 
pkg_hash_fetch_best_installation_candidate. It needs to look at the 
depended_upon_by array and select only candidates which don't break the 
constraints of each dependent package it finds.

If you want to try fixing this yourself I'll happily take a patch. Otherwise 
I'll look at it myself when I can.

Original comment by paul.betafive on 13 Mar 2014 at 7:28

Added labels: Milestone-0.3

GoogleCodeExporter commented 8 years ago

I've added a test for this issue in the latest git commit to the master branch. 
The test currently fails as expected.

Original comment by paul.betafive on 22 Mar 2014 at 5:49

GoogleCodeExporter commented 8 years ago

Hi paul.betafive,

this problem is still present. We (MLD team) are not able to fix the problem by 
ourself. So we hope that you can have a deeper look into it and hopefully fix 
it easily.

just to show you how urgent a fix of this problem is for us:

The MLD is a small linux distribution using the opkg as packagemanager. 
Currently there are about 300 users that can run into an broken system after 
upgrading.
After a reboot the System will not boot anymore if the cases that claus 
scetched above accure.

We hope that you can help us.

Thank you very much

Best Regards

MarMic

Original comment by marmic.h...@gmail.com on 13 Jun 2014 at 8:34

GoogleCodeExporter commented 8 years ago

I decided to rush through an attempt at a fix, which I've attached to this 
reply. It should at least catch the problem, report it and fail to install the 
package without breaking anything. Could you check that it correctly reports 
that the offending package cannot be upgraded?

If this does catch the problem, is reporting the error and failing an 
acceptable result? I don't think automatically upgrading an installed package 
which is not listed on the command line and is not a dependency of a package 
listed on the command line is a good idea. Instead I think the user should 
receive an error and then be able to re-execute opkg with the correct arguments.

Eg for the case discussed above:
`opkg install b` fails, refusing to upgrade B to 1.1
`opkg install a` or `opkg upgrade` succeeds, upgrading both A and B to 1.1

The attached patch should apply to the latest release (opkg-0.2.2).

I'm not confident enough to apply this patch to the tree yet, I'd like to get 
your feedback on whether it works first and run a couple more tests myself.

Original comment by paul.betafive on 13 Jun 2014 at 10:02

Attachments:

0001-WIP-opkg_install-Check-reverse-dependencies-before-i.patch

GoogleCodeExporter commented 8 years ago

I have add the patch, but it seems to have no effect. An upgrade or install 
brakes the dependencies like before.

Original comment by muuscl...@gmail.com on 14 Jun 2014 at 9:13

GoogleCodeExporter commented 8 years ago

Damn.

That is strange though. The patch fixes the test case I created (in 
'tests/regress/issue124.py') and also fixes the similar case with a third 
package 'C' which depends on 'B (= 1.1)'.

I must be missing something about your particular case. Could you send me a 
copy of the 'Packages' files which list the available packages and the output 
of 'opkg info <pkg>' for the relevant packages before the upgrade (the relevant 
packages would be those which muusclaus means by A, B  and C in comment #4). 
With that information I should hopefully be able to re-create what is going on.

Original comment by paul.betafive on 15 Jun 2014 at 12:37

GoogleCodeExporter commented 8 years ago

I will do so tomorrow.
I can also give you an ISO image with that you can make your own tests. That 
ISO is based on Ubuntu 64 Bit and about 10MB small. So if you also use Ubuntu 
to compile opkg it would be possible to replace the opkg-cl tool and do your 
own tests. If you are interested, I will give you a download link and a 
description how I take my tests.

Original comment by muuscl...@gmail.com on 15 Jun 2014 at 11:48

GoogleCodeExporter commented 8 years ago

Excuse me, that I don't answer yesterday.
Here I have the information you are requested for:

A = network
B = kernel
C = hid

MLD> opkg info kernel

Package: kernel
Version: 3.15.0.64-68
Depends: libc6 (>= 2.19-2)
Status: unknown ok not-installed
Section: system
Architecture: x86_64
Maintainer: Claus Muus <mld@clausmuus.de>
Size: 3493114
Filename: kernel_3.15.0.64-68.opk
Description: The Linux Kernel

Package: kernel
Version: 3.14.2.59-62
Depends: libc6 (>= 2.19-11)
Status: install user installed
Architecture: x86_64
Installed-Time: 1402101500

MLD> opkg info network

Package: network
Version: 0-27_3.15.0.64
Depends: kernel (>= 3.15.0.64), kernel (<= 3.15.0.64-:), libc6 (>= 2.19-9)
Status: unknown ok not-installed
Section: network
Architecture: x86_64
Maintainer: Claus Muus <mld@clausmuus.de>
Size: 839034
Filename: network_0-27_3.15.0.64.opk
Description: Treiber für Netzwerkkarten
 Enthält nur die üblicherweise verwendeten Treiber 
 (3c59x 8139too atl1 atl1c atl2 alx b44 cdc_ether dm9601 e100 e1000 e1000e forcedeth natsemi ne2k-pci pcnet32 r8169 sis190 sis900 skge tg3 tulip uli526x via-rhine via-velocity)

Package: network
Version: 0-26_3.14.2.59
Depends: kernel (>= 3.14.2.59), kernel (<= 3.14.2.59-:), libc6 (>= 2.19-11)
Status: install user installed
Architecture: x86_64
Installed-Time: 1403041756

MLD> opkg info hid

Package: hid
Version: 0-0_3.15.0.64
Depends: kernel (>= 3.15.0.64), kernel (<= 3.15.0.64-:)
Status: unknown ok not-installed
Section: 
Architecture: x86_64
Maintainer: claus
Size: 10558
Filename: hid_0-0_3.15.0.64.opk
Description:

Original comment by muuscl...@gmail.com on 17 Jun 2014 at 10:29

Attachments:

Packages

GoogleCodeExporter commented 8 years ago

The problem here is the depends line:
    kernel (>= 3.15.0.64), kernel (<= 3.15.0.64-:)

In the second constraint, opkg is interpreting the ':' as the separator between 
the epoch number and the version number. It should instead only interpret a 
colon as the epoch separator if it occurs before any non-numeric characters. 
The patch I posted is still needed, I'll need to make a second patch to be 
applied as well as that one. Once I've tidied up a couple more bugfixes I'll 
bundle them together into a v0.2.3 release.

In the meantime, you can fix this by using something other than ':' at the end 
of the version constraint. ';' works if you want something which compares 
greater than numeric characters and '|' works if you want something which 
compares greater than all alphanumeric characters.

Original comment by paul.betafive on 18 Jun 2014 at 11:06

GoogleCodeExporter commented 8 years ago

Thank you for the clarification. Did I can also use a '~' instead? Or do you 
know, what is the typically character there for? I do not remember why I decide 
to use the colon two years ago.

Original comment by muuscl...@gmail.com on 18 Jun 2014 at 12:54

GoogleCodeExporter commented 8 years ago

'~' didn't seem to work for me. I'd try '|'. I'm currently testing a patch 
series which should fix the version string parsing as well as the dependency 
checking in a better way. I'll post it here as soon as it's tidied up.

Original comment by paul.betafive on 18 Jun 2014 at 12:56

GoogleCodeExporter commented 8 years ago

OK, than I know, why I don't used it before ;)
I have changed it to ';' for a first fix.

Original comment by muuscl...@gmail.com on 18 Jun 2014 at 1:09

GoogleCodeExporter commented 8 years ago

I've attached an updated patch series which should do a much better job of 
fixing the issue. The first patch fixes the version parsing so you can use ':' 
in your dependency constraint if you wish to. The 2nd-4th fix the dependency 
checking with a little code tidy up and the 5th ensures users don't see the new 
notice about a package not being selected twice.

If this works for you I'll mark this as fixed and merge these patches to the 
opkg-0.2.x branch.

Original comment by paul.betafive on 18 Jun 2014 at 1:41

Attachments:

GoogleCodeExporter commented 8 years ago

This patches are not the best solution. Now it's not possible to upgrade any of 
the depended packages. In my example, it's not possible to upgrade the kernel 
(B) and also not the network package (A).
It's ok, that I can not upgrade packages, that needs a newer depended package, 
but I can also not upgrade the depended package it self.

Original comment by muuscl...@gmail.com on 19 Jun 2014 at 3:01

GoogleCodeExporter commented 8 years ago

I'm struggling to reproduce the failure to upgrade the network package (A) in 
this situation. After applying the patches, 'opkg upgrade B' fails but opkg 
upgrade 'A' succeeds and upgrades both A and B. Could you send me the exact 
error message you're seeing and I'll try to track down the cause.

Original comment by paul.betafive on 19 Jun 2014 at 7:08

GoogleCodeExporter commented 8 years ago

Here I have the the requested message (the last message of my log) and some 
further informations. I have used the same installation as in my post #12

MLD> opkg list-installed | grep -v lib
base - 0-45
btrfs - 3.12-46
busybox - 1.22.1-19
init - 0-30
install - 0-46
install-net - 0-10
kernel - 3.14.2.59-62
ldconfig - 2.19-9
locales - 0-5
network - 0-26_3.14.2.59
opkg - 0.2.2-50
psplash - 2009.05.28-17
ssh - 0-5
udev - 204-25
webserver - 0-113
xfs - 0-4

MLD> opkg upgrade network
Upgrading network from 0-26_3.14.2.59 to 0-27_3.15.0.64 on root.
Downloading 
http://www.minidvblinux.de/download/4.0.1-64/files/base/network_0-27_3.15.0.64.o
pk.
Not selecting kernel 3.15.0.64 as installing it would break existing 
dependencies.
Not selecting kernel 3.14.2.59 as installing it would break existing 
dependencies.
Not selecting kernel 3.15.0.64 as installing it would break existing 
dependencies.
Not selecting kernel 3.14.2.59 as installing it would break existing 
dependencies.
Not selecting kernel 3.15.0.64 as installing it would break existing 
dependencies.
Not selecting kernel 3.14.2.59 as installing it would break existing 
dependencies.
Not selecting kernel 3.15.0.64 as installing it would break existing 
dependencies.
Not selecting kernel 3.14.2.59 as installing it would break existing 
dependencies.
Collected errors:
 * pkg_hash_fetch_best_installation_candidate: Packages for kernel found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for kernel found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for kernel found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for kernel found, but incompatible with the architectures configured
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for network:
 *  kernel (>= 3.15.0.64) *     kernel (<= 3.15.0.64-:) * 

MLD> opkg upgrade kernel
Not selecting kernel 3.15.0.64 as installing it would break existing 
dependencies.

But I think there is an mistake in your last post. You are writing that it 
should be possible to upgrade A but not B. I think it must be the opposite. 
Since B is the kernel, and A stays for network and some other packages that 
needs a special version of A, I think the kernel (B) must be the package that 
should be upgrade able (and automatically upgrade all A packages).

Claus

Original comment by muuscl...@gmail.com on 19 Jun 2014 at 8:35

GoogleCodeExporter commented 8 years ago

I still think that 'opkg upgrade pkg' should only upgrade pkg and dependencies 
of pkg, I don't think it should upgrade packages which depend upon pkg. For 
example, I don't think 'opkg upgrade libc6' should upgrade every package on the 
system which depends on libc6. And just updating packages which have a 
dependency on a newer version of libc6 could be very confusing for the user.

There may be an argument for adding an option to upgrade reverse dependencies 
but I'd like to focus on fixing the bug at the minute as my time to work on 
opkg is limited.

I can't reproduce the failure of 'opkg upgrade network' that you're seeing. 
Could you apply the attached patch on top of the rest and try 'opkg -V4 upgrade 
network' and post the output? That should print a lot of debug output which 
would help track down exactly which dependency is breaking.

Original comment by paul.betafive on 22 Jun 2014 at 11:15

Attachments:

0001-WIP-pkg_breaks_reverse_dep-Improve-debugging-output.patch

GoogleCodeExporter commented 8 years ago

I have attached two logs. 
In the first log, only the network package depends on the kernel. This upgrade 
works.
In the second log, also the btrfs package depends on the kernel. This upgrade 
fails. In this case, I have no chance to upgrade any of the 3 packages (kernel, 
network, btrfs).

Original comment by muuscl...@gmail.com on 22 Jun 2014 at 12:41

Attachments:

GoogleCodeExporter commented 8 years ago

Just a quick update to say sorry I've not been able to work on this last week 
due to other commitments. I'll try to get back to this before the end of the 
week.

There isn't really an easy solution to this that I'll be happy with though. The 
correct solution is to overhaul the package installation method so that opkg 
prepares a list of all actions to perform, sets the package flags appropriately 
for all packages which will be changed in some way and then executes each 
action in turn.

The current method is just to handle each upgrade/install in isolation, so in 
your case even if you run 'opkg upgrade network btrfs', the dependencies of the 
old btrfs package will block the kernel upgrade needed to complete the network 
upgrade. With the changed method, opkg would know while upgrading network that 
a btrfs upgrade would follow, and it could check against the dependencies of 
the new btrfs version instead of the old one.

That behaviour change is too drastic for the 0.2.x branch though and in my plan 
was scheduled to happen after the 0.3.0 release and be included in the 0.4.0 
release. I may have to think of a hack that will allow opkg to handle your 
situation in the meantime.

Original comment by paul.betafive on 30 Jun 2014 at 11:05

GoogleCodeExporter commented 8 years ago

Ok, here's my proposed solution.

'opkg upgrade network btrfs' will by default still work the old way and hence 
fail in your situation. This can't be changed as it may break things for other 
use cases and I don't want to change the default behaviour drastically on a 
stable branch like opkg-0.2.x.

If the command line option '--combine' or the config file option 'combine' is 
given, the upgrade or install actions given on the command line may be 
combined. For now, it will combine just what it needs to to ensure that your 
situation will work. Going forward it will do what most other package managers 
do - resolve all dependencies first, then download all needed packages, then 
unpack all needed packages, then run all post-install scripts. This behaviour 
will then become the default (either in 0.3.0 or 0.4.0) and the 'combine' 
option will no longer be needed.

That path should ensure that nothing breaks unexpectedly.

Original comment by paul.betafive on 3 Jul 2014 at 12:28

GoogleCodeExporter commented 8 years ago

Hi,

you have forgot to add the new patch, or where can I found the new 
functionality?
And how must I enter the "combine" option to a config file, to activate this by 
default?

Original comment by muuscl...@gmail.com on 3 Jul 2014 at 3:39

GoogleCodeExporter commented 8 years ago

Sorry, that's just a proposal so far. I'm hoping to get some time to work on it 
over the next week. I just thought I'd share my ideas up front.

The syntax in the config file will be 'option combine 1'.

Original comment by paul.betafive on 3 Jul 2014 at 3:49

GoogleCodeExporter commented 8 years ago

OK, than I understood your last post wrong.
It's grate, that you share your ideas...

Do you checkin all your work to the git, so that I can simply checkout the 
master branch to get also the posted patches? Or should I (as I do at the 
moment) use the 0.2.2 download and patch it.

Original comment by cm...@google.com on 3 Jul 2014 at 3:55

GoogleCodeExporter commented 8 years ago

There's now a long list of patches so I have set up a publicly readable 
repository to push branches to. The patches which should fix this are now in 
the branch 'for-0.2.3/fix-124' in the repository at 
https://bitbucket.org/betafive/opkg.git.

That branch is based on the 'opkg-0.2.x' branch which now contains a couple of 
other fixes as well. You should be able to see details in the git log if you're 
interested.

Original comment by paul.betafive on 7 Jul 2014 at 8:41

GoogleCodeExporter commented 8 years ago

Thank you!
It seems to work.

Original comment by muuscl...@gmail.com on 7 Jul 2014 at 11:28

GoogleCodeExporter commented 8 years ago

I'm going to do some further review and testing on that code before merging it 
onto the opkg-0.2.x branch but it's good to know that it's working for you.

As an aside, I think this is at least 3 bugs solved here! (bad parsing of 
version strings including colons, failure to ensure that packages to be 
installed will meet the dependency constraints of packages already installed, 
failure to resolve dependencies correctly when installing/upgrading multiple 
packages at once).

A bugfix release, v0.2.3, will be made soon after these fixes are merged.

Original comment by paul.betafive on 7 Jul 2014 at 11:46

GoogleCodeExporter commented 8 years ago

I have a further question. Is is possible to hibe some of the messages. At the 
moment I get on upgrade for every package lots of this message: "Not selection 
kernel 3.14.0.64 as installing it would brake existing dependencies". I get 
this also if I use the option --combine and the upgrade works well.
It's ok to show this message (one time not several times) if I do not use the 
--combine option and the upgrade fails. But if the upgrade will be done, I do 
not need this message.

Original comment by muuscl...@gmail.com on 7 Jul 2014 at 12:19

GoogleCodeExporter commented 8 years ago

I have a further comment.
If I call a "opkg --combine list-upgradable" I get this message (also without 
the --combine option): "Not selecting kernel 3.15.4.64 as installing it would 
break existing dependencies."
I think, this message will be OK, if I do not use --combine, but not with this 
option.
Also I think this message should also be shown (if --combine is not given) for 
e.g. the network package, witch depends on the kernel. But that package will be 
shown normal as upgrade able.
Is it possible to remove this message if --combine is set and shown the kernel 
normal as upgrade able?

Original comment by muuscl...@gmail.com on 11 Jul 2014 at 11:31

GoogleCodeExporter commented 8 years ago

It does sound like the number of notices emitted by opkg in these cases would 
get rather annoying. I'll have a look at what I can do to reduce them now that 
the behaviour of opkg seems to be correct.

Original comment by paul.betafive on 11 Jul 2014 at 1:15

GoogleCodeExporter commented 8 years ago

I've pushed a couple of further changes to the branch on bitbucket, they should 
clean up a couple of bugs I noticed I had introduced (incorrect state_want 
values, incorrect handling of held packages) and should reduce the number of 
"Not selecting..." notices you see. I've ensured this passes the test suite but 
it does still need further review before merging to the opkg-0.2.x branch.

These changes might not catch all the unwanted "Not selecting..." notices so 
could you try out these changes and send me the output produced by opkg? We can 
then look at whether there are more messages we need to remove.

Original comment by paul.betafive on 14 Jul 2014 at 2:13

GoogleCodeExporter commented 8 years ago

The 'for-0.2.3/fix-124' branch has passed all my local tests so it's ready to 
merge to opkg-0.2.x in preparation for a v0.2.3 release in the next couple of 
weeks.

I'd just like to check if my recent changes reduced the number of notices you 
were getting from opkg. It should be much better now, let me know if it isn't.

Original comment by paul.betafive on 25 Jul 2014 at 12:05

GoogleCodeExporter commented 8 years ago

I'd like to move forward so I've merged the changes I have to both the 
opkg-0.2.x and master branches. I think we can call this fixed now unless 
there's anything I've missed.

Original comment by paul.betafive on 1 Aug 2014 at 10:36

Changed state: Fixed

GoogleCodeExporter commented 8 years ago

Now I have a new problem. If a package depends on two packages and the package 
and both depended packages should be upgraded, this is not possible and the 
upgrade call will only upgrade one of the depended packages.

e.g.:
The control files of the installed packages looks like this:
Package: A
Version: 1.0
Depends: B (= 1.0), C (= 1.0)

Package: B
Version: 1.0

Package: C
Version: 1.0

The new packages looks like this:
Package: A
Version: 1.1
Depends: B (= 1.1), C (= 1.1)

Package: B
Version: 1.1

Package: C
Version: 1.1

If I do a "opkg upgrade" only package C will be upgraded. Package A and B will 
be the old one.

Sins it is complicated to simulate this problem on a real system (there are 
lots of other dependencies), I'm not really sure, if the reason for the problem 
is a other side effect. 
Maybe it's important, that until my tests, there was also a package D installed 
that depends on package C like this:

The control file of the installed packages D looks like this:
Package: D
Version: 1.0
Depends: C (= 1.0)

The new package D looks like this:
Package: D
Version: 1.1
Depends: C (= 1.1)

I also have a further problem, that maybe occur on the first one. 
If I now do a "opkg remove A", the the package A will be removed from the list 
of installed packages, but all files of package A will stay on the system. No 
files will be removed.

Original comment by muuscl...@gmail.com on 18 Aug 2014 at 3:02

GoogleCodeExporter commented 8 years ago

I can't replicate either of those failures. With just A, B and C installed, 
"opkg upgrade A" or "opkg upgrade" works and upgrades all three packages. With 
A, B, C and D installed, "opkg upgrade --combine" or "opkg upgrade --combine A 
D" is needed as the dependencies of A and D must be considered together.

Are you using the opkg-0.2.x branch from git://git.yoctoproject.org/opkg or are 
you using some other version?

Original comment by paul.betafive on 18 Aug 2014 at 5:54

GoogleCodeExporter commented 8 years ago

I use the for-0.2.3/fix-124 version from git clone 
https://bitbucket.org/betafive/opkg.git 
Also I use the --combine Option.
Tomorrow I will create some test packages, to check again my reported problem.

Original comment by muuscl...@gmail.com on 18 Aug 2014 at 8:04

GoogleCodeExporter commented 8 years ago

I have found that my changes have exposed a couple of other dependency 
resolution bugs. They're not related to the original case here so issue 124 
remains closed.

I've opened issue 141 to track the newly exposed bugs. You may want to follow 
that issue and retry the opkg-0.2.x branch from git://git.yoctoproject.org/opkg 
once I've fixed it.

Original comment by paul.betafive on 19 Aug 2014 at 5:05

GoogleCodeExporter commented 8 years ago

OK. What is now the best branch (and git url) to follow all your updates to 
this issue and the issue 141?

Original comment by muuscl...@gmail.com on 19 Aug 2014 at 8:07

GoogleCodeExporter commented 8 years ago

It should be that opkg-0.2.x branch I mentioned, should be pushing patches 
tomorrow.

Original comment by paul.betafive on 19 Aug 2014 at 8:32

GoogleCodeExporter commented 8 years ago

I have found the reason for my Problem described in 
https://code.google.com/p/opkg issues/detail?id=124#c37 The reason is a package 
that gets a version downgrade. The newest version of the problematic package, 
that depends on other packages, has a lower versions number. Because of this, 
opkg do not want to "upgrade" this package, and it blocks the upgrade of some 
other packages. So, this is a problem of how I generate the package versions 
numbers, and not of the opkg package manager.

Original comment by muuscl...@gmail.com on 22 Aug 2014 at 12:19

GoogleCodeExporter commented 8 years ago

Is there a simple way, to let a package with a small versions number shown as a 
newer one?
e.g.:
the old package has this versions number:
2014.06.20-1
and the new one this:
2014.05.20-2

On debian packages I often se a "1:" or a 2: prefix in versions numbers. Does 
such a prefix prefix has a higher priority than a normal number?
e.g.
than the new versions number will be like this:
1:2014.05.20-2

Does this number has ha higher priority?

Original comment by muuscl...@gmail.com on 22 Aug 2014 at 12:55

GoogleCodeExporter commented 8 years ago

opkg parses versions much like dpkg does, so the Debian Policy Manual explains 
this: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

So in your example, "1:2014.05.20-2" would be higher than "2014.06.20-1". This 
is because "2014.06.20-1" is interpreted as "0:2014.06.20-1".

Original comment by paul.betafive on 22 Aug 2014 at 1:08

GoogleCodeExporter commented 8 years ago

Thanks, that is the solution fro my problem.

Original comment by muuscl...@gmail.com on 22 Aug 2014 at 1:33

GoogleCodeExporter commented 8 years ago

Now I have a further question to my last problem. Currently I get no message, 
until an upgrade, that tells my witch package blocks an upgrade. Is it possible 
to show a list of packages that blocks an upgrade and is it possible to get an 
option, that allow to force the upgrade with uninstalling the blocking packages?

Original comment by muuscl...@gmail.com on 23 Aug 2014 at 9:51

GoogleCodeExporter commented 8 years ago

I don't think comments on the issue tracker is the best place to discuss this 
as it isn't related to resolving the original issue. Could you ask that on the 
mailing list instead?

Original comment by paul.betafive on 23 Aug 2014 at 12:24

GoogleCodeExporter commented 8 years ago

OK, I created a simple test for 
http://code.google.com/p/opkg/issues/detail?id=124#c37.
In my scenario I use meta package that has ~50 dependencies on other packages 
with exact (=) version binding to ease the upgrade process and to be sure that 
everything is installed.
"c" package represents meta package in attached test. Currently test fails.
I use "master" branch (rev 7e2942).

Also I have some comments on 
http://code.google.com/p/opkg/issues/detail?id=124#c3.
Package managers such as "apt" or "yum" upgrade all packages that have any 
dependencies on each other to satisfy them. I think that this is a right way, 
specially on embedded platforms with sometimes unattended installation of 
packages. So "blocking" mechanism is not a good idea.

Original comment by KirG...@gmail.com on 4 Jan 2015 at 11:42

Attachments:

21_upgrade_depends.py

GoogleCodeExporter commented 8 years ago

Today I fond the reason, why many upgrades fails. Here is a simple example, 
that force the error:

e.g.:
The control files of the installed packages looks like this:
Package: A
Version: 1.0

Package: B
Version: 1.0
Depends: A (= 1.0)

Package: C
Version: 1.0
Depends: A (= 1.0), B (= 1.0)

Package: D
Version: 1.0
Depends: A (= 1.0), B (= 1.0)

Now upgrades for all packages are available. The new packages looks like this:
Package: A
Version: 1.1

Package: B
Version: 1.1
Depends: A (= 1.1)

Package: C
Version: 1.1
Depends: A (= 1.1), B (= 1.1)

Package: D
Version: 1.1
Depends: A (= 1.1), B (= 1.1)

In this case the upgrade (--combine) fails completely. In some more complex 
scenarios I have the bigger problem, that some packages will be upgraded, and 
some not. As result I will have a broken system.

It will be great if you can fix this issue soon, since we have really big 
problem with this issue and lots of broken systems during the last month.

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

dskvr / opkg

Upgrade of a package do not upgrade the depends #124