Do we have any documentation on package dependencies and versions

[Krishna Badam]

Hi All,

Is there any documentation,
For a newly installed OS(linux) what are the required kernel version, 
libraries, packages, tools and any version dependencies.

May not be for individual features, but at basic Mynewt OS level build 
dependencies.

I just want to have a pre-requisite check script, so the document can help me 
in preparing that.

Thanks,
Krishna B

Re: [DISCUSSION] Moving NimBLE to separate project

[Christopher Collins]

On Tue, Feb 27, 2018 at 08:39:04AM -0800, Christopher Collins wrote:
> I agree with others that the best option is 2a
> (@apache-mynewt-core/net/nimble* become empty packages that pull in the
> external nimble packages).  However, newt doesn't currently support repo
> dependencies; if a repo is not specified in the user's `project.yml`
> file, then newt won't download it.
[...]

I have submitted a PR which fixes repo dependencies:
https://github.com/apache/mynewt-newt/pull/140.  

This PR changes the `repository.deps` format to the one I used in my
previous email.  I thought this was a good idea because it eliminates
the need to repeat a depended-on repo's git information for each
version.

> 
> I've been looking at repo dependencies in newt, and it appears to be a
> pretty complex feature.  I don't think we can expect to have this
> working for 1.4.0, but maybe there are some compromises we can make to
> implement a simplified model that solves the nimble case.  I'll explain
> why I think this is complicated to solve below.  If you aren't
> interested in newt particulars, feel free to stop reading now :).
> 
> Here is how apache-mynewt-core's `repository.yml` file might look like
> this after the nimble and nffs dependencies are added (I've made some
> syntax changes for readability):
> 
> repository.deps:
> mynewt-nimble:
> type: git
> url: 'g...@github.com:apache/mynewt-nimble.git'
> vers:
> master: 0-dev
> mynewt_1_4_0_tag:   >=1.4.0
> 
> mynewt-nffs:
> type: git
> url: 'g...@github.com:apache/mynewt-nffs.git'
> vers:
> master: 0-dev
> mynewt_1_4_0_tag:   1.4.0
> 
> What this says is:
> * The master branch of apache-mynewt-core depends on:
> o nimble 0-dev
> o nffs 0-dev
> * The mynewt_1_4_0_tag tag of apache-mynewt-core depends on:
> o nimble 1.4.0 or later
> o nffs 1.4.0 only
> 
> The key points are: 
> * A repo's dependency tree may differ with version (branch).  
> * A dependency can specify a range of dependant repos (e.g., `>=`).
> 
> I think this is a good design, and I am not suggesting changing it.
> Some aspects of this are just quite complicated.  In particular, if the
> user wants to upgrade some repos, calculating the versions to upgrade to
> is a bit tricky.  Newt solves the similar problem of determining which
> packages to include during a build operation, but there is a fundamental
> difference: for packages, there is only a single dependency graph.  For
> repos, on the other hand, there are potentially many separate graphs,
> each of which needs to be evaluated to detect conflicts.  Furthermore,
> each graph may differ quite substantially, as some secondary dependency
> may add a tertiary dependency for certain versions (and so on and so
> on).  The number of potential graphs is quite large.  Consider a project
> with 10 repos, each of which specifies 10 versions in its
> `repository.yml` file.  Ignoring some details, there are potentially
> 10^10 (10 billion) graphs that would need to be evaluated to find the
> one combination that doesn't have any conflicts.  Furthermore, producing
> a helpful error message when there is no suitable combination of repo
> versions is quite a challenge in itself.
> 
> Linux distributions that use a rolling release model solve this problem,
> so it certainly is possible to implement.  However, it is going to
> require a lot of tricky code.
> 
> Chris
> 
> On Tue, Feb 27, 2018 at 09:44:37AM +0100, Szymon Janc wrote:
> > Hi,
> > 
> > 1. I'm fine with doing it either before or after 1.4. We just need to
> > make sure update works correctly for 1.4 if we do it before.
> > 2. I'd go with 2a as Will,  no need to keep duplicated code around.
> > 3. Agree with Will,  lets start with 1.0 NimBLE release. Only the
> > first release needs to be coordinated with -core anyway.
> > 
> > 
> > On 24 February 2018 at 01:07, will sanfilippo  wrote:
> > > My thoughts:
> > >
> > > 1. Since the 1.4 release is coming up very quickly I would do this for 
> > > 1.5 (personally).
> > > 2. I would choose 2a.
> > > 3. Seems a bit confusing to me to label nimBLE releases with same number 
> > > as Mynewt releases. Why not just make the first stable release of nimBLE 
> > > 1.0? Not a big deal either way but since they are going to diverge 
> > > eventually.
> > >
> > > Will
> > >> On Feb 22, 2018, at 1:01 AM, Andrzej Kaczmarek 
> > >>  wrote:
> > >>
> > >> Hi all,
> > >>
> > >> As some of you may already noticed, there is apache/mynewt-nimble
> > >> repository created where NimBLE code was pushed along with some extra
> > >> changes, most notably initial attempt to create port of NimBLE for
> > >> FreeRTOS, but other platforms will be supported as well (native Linux 
> > >> port
> > >> is also prepared).
> >