On Fri, Nov 7, 2025 at 6:33 AM Daniel Wagenknecht <[email protected]> wrote: > > 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?
Correct > 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'd start with NOASSERTION. You can always post-process the SPDX to check for NOASSERTION after the build finishes if that's something you care about; then we can separate the discussion about whether that should be a build failure for later. I suspect many users will have different QA tests they can perform by post-processing the SPDX, which would remove the burden of needing to make builds fatal for everyone's specific (QA) use case. > > > 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 (#2197): https://lists.openembedded.org/g/openembedded-architecture/message/2197 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]] -=-=-=-=-=-=-=-=-=-=-=-
