On Mon, Jul 31, 2017 at 4:58 PM, Val Kulkov <val.kul...@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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev