Re: [OE-core] [PATCH] base/patch: Disable network for unpack/patch/configure/compile/install

[Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>]

Hi Konrad,

Am 24.12.21 um 11:36 schrieb Konrad Weihmann:
> I had a look at the failures and most of them are fairly easy to fix - 
> all but the go recipes like influxdb.

The go class doesn't work without network by default if the project 
doesn't provide a vendor folder.

> I'm not sure how to deal with that, so there aren't that many options here.

This is a common problem for all language specific package managers 
(python / pip, Node.js / npm, Rust / Carge, go) and we need a common 
solution.

> Either
> - inject all the needed with a fixed revision, but that would prevent 
> devtool from catching updates to them properly

This is possible if we extend recipetool to add the dependencies to the 
recipe. Rust and npm are using this option and I have a WIP to improve 
the npm solution. But in any case we loose a lot of advantages of OE.

> - create recipes for all of them and pray that there won't be a circular 
> dependency in any of them

The circular dependency is only the least problem and could be fixed by 
splitting the dependency and code into separate recipes. The main 
problem is the huge increase of recipe count and parse time. Furthermore 
we need the possibility to test recipe updates of dependencies. Python 
is using this option.

> - allow go to work with network (the least favorable option IMO)

This is how the current go and especially go-mod class work.

> in the case of influxdb for instance we are talking about
> 
> github.com/peterh/liner
> golang.org/x/crypto
> github.com/influxdata/influxql
> github.com/influxdata/flux
> github.com/BurntSushi/toml
> github.com/influxdata/usage-client
> golang.org/x/text
> go.uber.org/zap
> github.com/klauspost/pgzip
> github.com/prometheus/client_golang
> github.com/jsternberg/zap-logfmt
> github.com/mattn/go-isatty
> collectd.org
> github.com/bmizerany/pat
> github.com/dgrijalva/jwt-go/v4
> github.com/gogo/protobuf
> github.com/golang/snappy
> github.com/tinylib/msgp
> github.com/opentracing/opentracing-go
> golang.org/x/sync
> github.com/apache/arrow/go/arrow
> github.com/pkg/errors
> google.golang.org/grpc
> github.com/kraj/xxhash
> github.com/influxdata/roaring
> github.com/xlab/treeprint
> golang.org/x/time
> golang.org/x/sys
> github.com/jwilder/encoding
> github.com/dgryski/go-bitstream
> 
> where especially the golang.org/x modules are known to have circular 
> dependencies like x/a relies on x/b, while x/b requires x/c and x/c 
> needs x/a for building.

Isn't the circular dependencies problem mainly a problem of the native 
packages? In many cases the dependency only exists at compile time of 
the main project and not at compile time of the dependency itself. In 
case of a native package all dependency sysroots need to be finished 
before the recipe sysroot itself.

Regards
   Stefan