Hello Joshua, thanks for your remarks!
On Wed, 2025-11-05 at 09:53 -0700, Joshua Watt wrote: > On Wed, Nov 5, 2025 at 7:54 AM Daniel Wagenknecht via > > I don't think a variable to specify the public URL is going to work > well; for example, if a layer is forked, it will be wrong and > confusing. Agreed. My intention was to get the "public" URL for a layer, even if it was pulled from a fork. My naive assumption was, that this URL should point to a publically reachable location, but according to the SPDX documentation for the downloadLocation field it might just as well be an internal URL. This simplifies it. > Just thinking off the top of my head, a better option might > be a variable that specifies the name of the git remote that should be > used, and if it's not specified then the URLs are ignored? > [...] > which would use the "origin" remote of the oe-core git repo, and _if_ > the current SHA-1 of that repo (which bitbake already knows) is in > that remote, then it will use that remote as the URL. I like that approach! To clarify: this should not access the network but work with the local view of the repo only, right? I guess the local view of the remote could be out of sync (e.g. something was rebased on the remote), and if a commit is not part of a known branch of that remote (e.g. the commit exists in a tags history only) this would also yield a NOASSERTION value. > In this way, if > you fork you can choose to use your own remote, or for example pull in > upstream oe-core as an "upstream" remote and use that. > > I'm not entirely sold the above description is the best path, so maybe > we can let others chime in. Developing the thought further I think it would be fine to default to using the git origin remote as default and allow adapting it per layer. I'd then introduce an SPDX_REQUIRE_META_LAYER_ASSERTION (or similarly named) variabel to promote unasserted values (like layer dirty) to build failure. > I do think that we will want a way to > solve this, as we have also talked about including the information > about the layer itself into the SPDX, so this is more or less an > extension of that Yes, small steps. Working out how to refer to a layer to construct downloadLocations for individual files is only a first step, creating SPDXRef-Download-meta-layer entries for layers and refering to them would be a logical improvement. > > > Sincerely Daniel
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2198): https://lists.openembedded.org/g/openembedded-architecture/message/2198 Mute This Topic: https://lists.openembedded.org/mt/116137661/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
