Closed GoogleCodeExporter closed 8 years ago
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
Original comment by paul.betafive
on 12 Nov 2013 at 10:33
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
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
Original issue reported on code.google.com by
pacipriani
on 12 Nov 2013 at 10:23