[LEDE-DEV] Fwd: future-proofing opkg

[Mike Kelly]

On Mon, Jul 31, 2017 at 4:58 PM, Val Kulkov <val.kulkov at gmail.com> wrote:
> I am requesting feedback on how to make LEDE/OpenWrt a little more
> friendly to end users where an outdated version of opkg cannot install
> a package properly. A few possible approaches I can think of are:

Some approaches I've seen around this issue in the past, with other
package management systems:

FreeBSD's pkg-ng[1] will issue a warning if there is an updated
version of itself when you run general upgrade operations, and will
prompt you to upgrade it first.

MacPorts strongly encourages you to run a separate `port
selfupdate`[2], which is similar to `opkg update && opkg upgrade opkg`
wrapped into one (using the base OS's rsync to upgrade macports
itself).

In other distros, I think I may have seen either "require version X of
the package manager" or "conflicts with version less than X of the
package manager" specified in some cases like this.

Some distros also have versioning of the package metadata files
themselves, defining new formats when new features are added; the
package manager could then say "I don't understand this format!" and
bomb, rather than doing the Wrong Thing. In Exherbo[3], that's driven
by the filename of the package descriptor file, so no special parser
magic is required. In Gentoo, it's driven by an "EAPI"[4] variable
defined near the top of the "ebuild" file. This approach also means
that you can change the semantics of other parts of the package files
over time, changing some defaults, etc, and older package managers (at
least, those released after you've first supported this versioning
scheme) will know they can't handle it. Debian seems to offer a
similar feature as well, with "Standards-Version"[5] in the control
file.

[1] https://www.freebsd.org/doc/handbook/pkgng-intro.html
[2] https://guide.macports.org/#using.port.selfupdate
[3] https://exherbo.org/docs/eapi/exheres-for-smarties.html
[4] https://devmanual.gentoo.org/ebuild-writing/eapi/
[5] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Standards-Version