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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev