Enhancement to the "downgrade" functionality

[GoogleCodeExporter]

Below is described a ideal methodology of downgrade.

Suppose, to make things easier, that we are working with only one package, for 
example "testpackage_0.0.1_arm.opk​​",  installed in the system (opkg 
install testpackage_0.0.1_arm.opk).

After some time, a newer version of that package (testpackage_0.0.2_arm.opk) is 
available in the repository​. It is downloaded into the cache with the 
command "opkg upgrade --download-only​" and then installed with the command 
"opkg upgrade"​​.

After the upgrade, another update​ ​(testpackage_0.0.3_arm.opk) ​​is 
available in the repository and it is installed in the system as for the 
previous package.
​Now we have the version 0.0.3 of the package "testpackage" installed in the 
system.

Suppose now that we discover a bug in the software installed by 
"testpackage_0.0.3_arm.opk" and we need to rollback to the previous version: it 
would be very useful if the command "opkg install testpackage 
--force-downgrade" offered this function, installing the previous package, that 
is "testpackage_0.0.2_arm.opk".

At this point, we have in the local opkg cache three packages:
1. testpackage_0.0.1_arm.opk
2. testpackage_0.0.2_arm.opk
3. testpackage_0.0.3_arm.opk

When opkg downgrades to 0.0.2 version it should also tag the 
"testpackage_0.0.3_arm.opk" package "faulty": this is needed in order to ignore 
that version of the package in case of "opkg upgrade" command is executed, 
avoiding the re-installation of the bug-affected package.

When the bug-free version of the package "testpackage_0.0.3_arm.opk" is 
available in the repository (opkg can discover it because of a different MD5 
respect to tho one in cache, the datetime is more recent, or both...or similar 
strategies) it can be downloaded and installed... so the faulty version 
disappears.

I think this functionality can be very useful to the ones that want to use opkg 
to automate software upgrade/downgrade on embedded systems, putting opkg one 
step ahead respect to  other package managers.

Best regards,
Paolo

Original issue reported on code.google.com by pacipriani on 12 Nov 2013 at 10:23

[GoogleCodeExporter]

I would see this as putting too much policy into opkg itself. I'd like opkg to 
expose functionality which lets you write a script to do this.

I'd definitely support adding 'opkg install testpackage --force-downgrade 
--previous" to specify that you want to re-install the last version installed 
before the present version. Then you could issue 'opkg flag hold testpackage' 
to ensure that it isn't upgraded again until you've confirmed that the new 
version is good.

This needs some proper discussion and the mailing list is probably a better 
venue so that we could involve other people in the discussion. Could you send 
your proposal to opkg-devel@googlegroups.com please?

Original comment by paul.betafive on 12 Nov 2013 at 10:31

[GoogleCodeExporter]

Original comment by paul.betafive on 12 Nov 2013 at 10:33

• Added labels: Milestone-0.4, Type-Enhancement

[GoogleCodeExporter]

As requested, I sent the proposal to opkg-devel@googlegroups.com

Thank you,
Paolo

Original comment by pacipriani on 12 Nov 2013 at 10:40

[GoogleCodeExporter]

So there wasn't really any discussion about this issue when it was posted to 
the list. In the meantime I've modified the issue tracker to post all issues to 
the list so I shouldn't need to ask for that again.

But as to the issue itself:

> When opkg downgrades to 0.0.2 version it should also tag the
> "testpackage_0.0.3_arm.opk" package "faulty": this is needed in order to
> ignore that version of the package in case of "opkg upgrade" command is
> executed, avoiding the re-installation of the bug-affected package.

This is a policy I don't think opkg should force on the user. opkg doesn't know 
why you wanted to downgrade the package and on what future condition you want 
to allow an upgrade. Currently you can do the downgrade then mark the 
downgraded version as on hold. Then you need to test for yourself whether a new 
version of the package has the same bug or not.

> When the bug-free version of the package "testpackage_0.0.3_arm.opk" is
> available in the repository (opkg can discover it because of a different MD5
> respect to tho one in cache, the datetime is more recent, or both...or similar
> strategies) it can be downloaded and installed... so the faulty version
> disappears.

No. When the bug is fixed, the package version should be updated. This is why 
OpenEmbedded and others use versions like "0.0.3-r1", so if you fix the 
packaging but the upstream version number is the same you can call this 
"0.0.3-r2".

So this isn't something I plan to add to opkg.

Original comment by paul.betafive on 1 Feb 2014 at 2:02

• Changed state: WontFix