On 11/20/2016 08:26 PM, David Lang wrote: > replying to details other than the feeds concept/ > ... >> There were two different definitions offered. I'm guessing that you meant >> the >> "build number" after the "major.minor" version number. > > not quite > > the branch would be Year.Month, tags/builds within that branch would be > Year.Month.Build
Ok, I get that. > ... >> Hmm - it is still not clear to me how the term "branch" will apply here, >> because: 1) the hierarchy of "base.feeds" is referencing four *other* git >> repositories, each of which has its *own* "head" branch name, each of which >> - I >> assume - may be changed or selected independently; and 2) the "feeds" link >> list >> does *not* have any version information within it, itself. > > The branch is really based on the LEDE maintained git repository, ignoring the > feeds that are not maintained by LEDE or OpenWRT. > > There is an interesting question of how to refer to what state of each feed > you > use for a release. Currently OpenWRT doesn't even try to do this. The feed > version you get is the feed version that exists at the time you last pulled > from > the feeds. Uhm - I'm a bit taken aback by that. > This hasn't been a big problem in practice, but it does mean that you don't > really have a repeatable build. I would have thought that that was a "show stopper". It certainly does not inspire confidence. I say this is a "problem" and should be a high priority issue. > See my other e-mail about submodules for a > discussion on this. Yes, I looked at that. It would seem to address and solve a number of issues. There would be no need for a separate "manifest", and, most importantly, there would be a git "snapshot" of the *entire* project state. If I understand, that also means there would be a unique git tag that would label that state, and could be associated with any kind of specific nickname, version, and build number. It would mean that every build was repeatable. >> It would be possible, I suppose, that each of these linked repositories >> could be >> *required* to use the *same* versioned naming scheme. > > can't be done, these other repositories are not under our control. The most we > can do is reference exactly which release we use.. I see that now. > ... > actually, the LEDE/OpenWRT releases are long, they are trying to get them down > to only a year or so. > > What most people end up using is the roughly the equivalent of the nightly > builds, but even more granular in that people grab the source code and compile > it, so they get up-to-the-minute changes, not even nightly snapshots. I don't understand the point of having a LEDE "release" then. But then, I prefer using Arch, a rolling release distribution, where other people prefer something like Debian, for stability. So maybe LEDE would have a yearly "release" version for some people, and other people can grab the latest buildbot build? Or compile it themselves. With the git submodule idea, LEDE could have a repository that even includes the entire cross-compiler tool chain? Or maybe that's going too far? >> Cyanogenmod uses the term "manifest" instead of "feed", and uses "repo", a >> specialized "repository management tool that we built on top of Git." You >> are >> familiar? In a sense, the top level of the build system is the "manifest" >> file >> "default.xml" with its own web page, https://github.com/CyanogenMod/android. >> Hmm - LEDE has a program "[source.git] / scripts / feeds", which serves the >> same >> function as "repo", yes? Maybe I begin to understand. And then, the term >> "feed" would actually mean one of several git source code repositories >> enumerated in the LEDE "manifest". And "feeds" means a LEDE git repository >> management and build utility. > > more or less. OpenWRT was stuck for a long time using subversion instead of > git, > so things developed differently, but you seem to be mapping the concepts more > or > less correctly. Ok, thanks for confirming. >> I think that, essentially, I must understand how a LEDE build version number >> can >> be related to an instantaneous version of four independent git repositories. > > ignore the feeds for now, they are not part of the LEDE release. Yeah, I see now how that works - scary, but clarified. >> Would it be useful to version the manifest, and have the versioned manifest >> enumerate specific versions of the manifest components? I assume that each >> component could specify an instantaneous snapshot version of each master >> branch >> of that component? Perhaps git tags could be included inside the manifest, >> and >> no one would have to memorize or recognize or refer to these, because the >> manifest itself would have a human readable version number, as in >> "year-month-build". > > that would be inventing another layer of abstraction, I don't think we need to > do that. But this is the submodule discussion I raised in another branch of > this > thread. Again, git submodules would answer all of those issues. And there would be no need for another one-off custom build tool, like "repo" or "feeds". > ... > The first thing to do is to ignore the feeds and all software involved in > them.. Well, based on what I am understanding now, that would be an oversimplification, but I get the idea. >> The terminology would make more sense to me if "base" referred to a "base >> package" which include the linux kernel and required utilities, unique to >> each >> hardware system, > > it does. Ok, I'll assume that then. >> even though it were a "package" that could not be installed by >> opkg. As I understand, the kernel and the root file system have to be >> installed >> together, as a matched set, though I cannot say why. > > partly for historical reasons, partly because LEDE/OpenWRT are usually > installed > on systems that have very little storage, so you don't have a 'normal' > filesystem that you can replace different parts of, you have a compressed > filesystem where everything you are installing has to be combined into one > blob > and installed all at once. Ah! Thanks for that. On reflection, yes, of course. That makes sense. >> The "version number" would >> imply the version of this LEDE "base package". The LEDE "source" would >> refer to >> just the git repository "https://git.lede-project.org/";, and the git >> directory >> "source.git" would instead be named "build.git". The file >> "feeds.conf.default" >> could be called "manifest.default", which would be a concept shared with >> Cyanogenmod. > I hate to disappoint you, but Cyanogenmod's terminology is pretty unique to > it, > it's not universal. It makes more sense to you because you ran across it > first, > but changing the terminology in LEDE would just add to the confusion of the > exisiting LEDE/OpenWRT users and introduce incompatibilities with years of > documentation and how-tos > > The version does refer to the exact state of the LEDE maintained git > repository > (feeds are a different/complicating issue) Git submodules ;) > David Lang James _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
