[LEDE-DEV] Fwd: future-proofing opkg

[Val Kulkov]

The support for alternatives in LEDE was introduced recently [1] to
address the issue where multiple packages attempt to install the same
symlink. The method for alternatives support in LEDE is different from
that of Debian. In LEDE, an alternative is an attribute of package’s
CONTROL file: [1].

The support for alternatives solves the problem where the build system
detects an error and fails to build a package on attempt to install a
symlink that has already been provided by another package. Now the
symlink is created by opkg during package installation on a target
device after checking for an existing symlink and removing it if
necessary, rather than by the build system during the
installation/packaging phase (per instructions in
Package/<pkgname>/install section of pkgname’s Makefile).

The problem now is that the older versions of opkg that are not
alternatives-aware cannot properly install a package that has been
built with the Alternatives attribute. Apparently, the problem will go
away as soon as the user upgrades opkg to a version that supports
alternatives. However, until opkg is upgraded the user will be unable
to install a package properly and currently opkg will not give any
hints to the user as to why the installation on a target device is
failing.

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:

1. opkg displays a warning when it cannot recognize an attribute and
encourage user to upgrade opkg,
2. opkg provides a functionality similar to Perl’s “require v5.6.1;”
to enforce an opkg version that is no older than the specified
version,
3. opkg provides information about itself that package maintainers can
use to write future-proof preinst or postinst scripts.

In essence, this is a forward compatibility issue. It is a broad and
general issue. Approaches discussed here may very well be applicable
to other components of LEDE/OpenWrt.

[1] http://lists.infradead.org/pipermail/lede-dev/2017-March/006784.html