On 8.5.2016 7:35, John Crispin wrote:
On 06/05/2016 02:16, l...@daniel.thecshore.com wrote:
package/base-files/files/etc/openwrt_release | 7 --
package/base-files/files/etc/openwrt_version | 1 -
these 2 files cannot simply be removed as that would break luci.
we need to either create symlinks or teach luci to look for both or similar
John
The contents of those files, the related config options and the sources for
each items might maybe be rationalised at the same time.
"Designated Driver" is defined as RELEASE in include/toplevel.mk, which is
then used by include/version.mk for VERSION_NICK. It has always been a bit
confusing that the version/release branding has been split to /etc/banner,
include/toplevel.mk and include/version.mk. I think that LEDE has now
eliminated the hard-coded version name in /etc/banner, but /include/toplevel
still sets the primary version designation, while all other similar options
are set in include/version.mk
We might also re-think a bit the RELEASE, REVISION, VERSION_NUMBER,
VERSION_CODE, VERSION_NICK etc. logic. It is confusing that VERSION_CODE
cannot be configured, but is only either 15.05.1 if there is a version
number, or alternatively HEAD.
include/version.mk handles REVISION as an alternative input to
VERSION_NUMBER, but at least I see REVISION (like r75) as a different kind of
information than 15.05.1. And the naming is confusing as the VERSION_NICK
gets written into the DISTRIB_CODENAME line in /etc/openwrt_release, while
VERSION_CODE gets written to DISTRIB_RELEASE line.
There are at least four different kind of builds:
* trunk snapshots/builds: Trunk codename designation, no release number,
source revision, opkg download from snapshot repo
* branch builds before release: Branch codename designation, release branch
number known but no release yet, source revision
* branch release builds: Branch codename designation, official release
number, source revision, opkg download from release repo
* branch builds after a release: Branch codename designation, last release
number known + changes after it, source revision, opkg download from last
release repo
The naming/numbering options should support all of these. I have no ready
answers about the optimal solution, but thought to mention the issue, as this
might be the natural point to straighten up the logic.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
