opkg don't resume big upgrades

[GoogleCodeExporter]

What steps will reproduce the problem?
1. update, upgrade
2. reboot or interrupt while it is upgrading
3. redo it, it will start again with the full package set

What is the expected output? What do you see instead?
it should just upgrade the remaining packages and the one which has been
interrupted

What version of the product are you using? On what operating system?
opkg 0.1.6
shr 21072009

Please provide any additional information below.

Original issue reported on code.google.com by hariseld...@gmail.com on 3 Aug 2009 at 4:08

[GoogleCodeExporter]

it seems to work by interrupting it with ctrl+c, because before closing it 
saves info
on the db, but often on unstable platform the system freeze and the clean 
closing
feature cannot do nothing
maybe it could save info to db every 10 packets or so, in order to alleviate 
this
problem..

Original comment by hariseld...@gmail.com on 3 Aug 2009 at 6:40

[GoogleCodeExporter]

We need to establish whether this is still an issue.

Is the behaviour still present with the latest opkg release?

What does opkg do instead of resuming? If it repeats the whole upgrade without 
erroring out, is this really a problem?

And can an embedded package manager expect to maintain a stable state when the 
power is removed during an upgrade? Performing atomic upgrades would be quite 
heavy-weight to implement.

Original comment by paul.betafive on 28 Sep 2013 at 1:23

• Added labels: Milestone-1.0

[GoogleCodeExporter]

I think that can be implemented by using of filesystem snapshots.
There are few filesystems that support these feature, nilfs2 and btrfs in 
particular.
.
To deal with upgrade interrupting user can create snapshot of rootfs before 
upgrade.
If upgrade process is interrupted during power lost then on next boot user 
should use saved rootfs snapshot. That can be implemented in initramfs.

Original comment by KirG...@gmail.com on 2 Feb 2014 at 1:27

[GoogleCodeExporter]

I think packages being left half-installed here is a separate issue but as you 
say can be solved by filesystem snapshotting. That shouldn't be done by opkg, 
but opkg should have the scripting hooks so that you can add a script to take a 
snapshot before installing packages.

I think the issue here is that status files are only updated at the end of the 
upgrade or install command and not after each successful package install. It 
may be worth investigating the performance cost of updating status files after 
each package is installed and configured.

Original comment by paul.betafive on 3 Feb 2014 at 1:09