Am 27.12.21 um 15:54 schrieb Eero Aaltonen:
On Mon, 2021-12-27 at 14:38 +0100, Stefan Herbrechtsmeier via
lists.openembedded.org wrote:
Hi Alex,
Am 25.12.21 um 20:41 schrieb Alexander Kanavin:
On Sat, 25 Dec 2021 at 20:32, Stefan Herbrechtsmeier
<ste...@herbrechtsmeier.net <mailto:ste...@herbrechtsmeier.net>>
wrote:
> 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.
I tend to think that the best (and the hardest) option is to
improve these tools so that they're usable inside do_fetch (e.g.
fulfil the caching/reproducibility criteria for a bitbake fetcher),
and the needed changes are acceptable to upstreams.
The real problem is the different philosophy between OE and the
package manager. The package manager doesn't care about duplicate
versions, maintenance versions, version updates of indirect
dependencies, license compliance, CVE checks or dead code (examples,
documentations, test,
...) and if they care every package manager have its own solution.
The Java OSS ecosystem has had fairly well defined build time and
runtime dependency metadata commonly available for many years now. The
more widely used build tools are capable of using this metadata to
calculate a solution Set(lib, version) that satisfies the version
requirements of the dependency graph - or report that no solution is
available. Cryptographic hashes are however by default provided by the
artifact server(s).
For Python distribution packages, the 2020 pip resolver is advertised
to be better at calculating solutions to required package
dependencies. Cryptographic hashes are specified for pip, use is
optional. The PyPA Core metadata includes some potentially useful
fields, such as the license and what the project requires.
The language specific package managers could potentially be used to
export dependency metadata, and also potentially to check "with (foo
i.j.k) and (bar x.y.z), is there a set of compatible package versions
available for baz and it's dependencies?"
This is possible and already done in recipetool.
I see two possible solution to support language specific package managers:
a) Use the package manager manifest direct (go.sum, npm-shrinkwrap.json,
...) to fetch the dependencies.
b) Create recipes from the package manager manifest.
Either we give away the control over the dependencies and use the
language specific way of manage dependencies or we have to extract the
information as suggestion.
Everything between means that we lose the benefits from the language
specific package manager and OE together.
Regard
Stefan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160032):
https://lists.openembedded.org/g/openembedded-core/message/160032
Mute This Topic: https://lists.openembedded.org/mt/87909311/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
