Am 12.02.2025 um 10:38 schrieb Richard Purdie:
On Wed, 2025-02-12 at 10:27 +0100, Stefan Herbrechtsmeier wrote:
Am 11.02.2025 um 22:31 schrieb Richard Purdie:
On Tue, 2025-02-11 at 16:00 +0100, Stefan Herbrechtsmeier via
lists.openembedded.org wrote:
From: Stefan Herbrechtsmeier<stefan.herbrechtsme...@weidmueller.com>
Add a vendor package as base for package manager specific
implementations to resolve dependencies and populate vendor directories.
Add common dump and load function for SRC_URI files.
Signed-off-by: Stefan Herbrechtsmeier<stefan.herbrechtsme...@weidmueller.com>
---
meta/lib/oe/vendor/__init__.py | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 meta/lib/oe/vendor/__init__.py
Initially I was going to ask there to be a "fetch" or "download" in the
namespacing. That then made me wonder if in the interests of clarity
and namepacing, these vendor classes should go into
lib/bb/fetch2/vendor in bitbake?
The package isn't limited to fetch / download. In some cases it
populate the vendor directory and could be used for the license
extraction in future.
"populate" and "extraction" sound related to the fetcher.
I think it is a bad idea to move code into bitbake which isn't used
by bitbake. It will complicate future development without any
benefit.
You could argue that about the fetch module. It does encourage
strong/stable APIs to the modules, which has been of benefit. I can see
the arguments either way though.
At the moment there is no common api between the different resolve
functions. The different package manager need different details. But it
is possible to unify the functions parameters.
Where would you place the code in bitbake?
I appreciate the class in OE will use them and separation into bitbake
can be a bit awkward but it would mean we don't confuse this with any
other kind of vendoring
What do you mean by "any other kind of vendoring"?
When someone customises their BSP, the original might be from "the
vendor" so perhaps this code handles that? OSV as in software vendor is
going to get confused with this. I'd imagine there will be other ways
people could read it too. We have TARGET_VENDOR, HOST_VENDOR,
SDK_VENDOR and so on in the triplets.
What name do you recommended?
My point is that if someone sees a "vendor" module in isolation, they
aren't going to know what it relates to. You're really close to this
topic so it is obvious to you, it is not going to be obvious to others,
or perhaps even you in a few years time.
I fear names like dependencies, package manager or resolver are
misleading too.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211229):
https://lists.openembedded.org/g/openembedded-core/message/211229
Mute This Topic: https://lists.openembedded.org/mt/111123519/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
