On 17. 05. 22 21:49, Miro Hrončok wrote:
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change
proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Also, when you say "after F38 branching", does that mean it will not be
allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names.
No change there. The same for epel9-.
Do we need to %if-%else it in the spec file? I recall some discussion about
this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And
yes, it works.
I just got an idea. Do I assume right that while the old Fedora tags -> SPDX
mapping is ambiguous, but the reverse is well defined? If that's the case, can
we make a macro that would:
1. Validate an SPDX expression for correct syntax, errors if invalid
2. On Fedora > X || RHEL > Y returns the input unchanged
3. On older releases, converts all names from the input to the old names
(possibly de-duplicating matching groups)
You would use it like this:
License: %{spdx BSD-3-Clause and BSD-2-Clause}
This would evaluate to either of the following depending on the release:
License: BSD-3-Clause and BSD-2-Clause
or
License: BSD
Does that make sense? If we package spdx2fedora data in a Lua-readbale form, I
believe I can draft a naïve implementation of that macro.
Here is an absolutely naïve proof of concept. It does not validate and it does
not deduplicate.
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3
I also see that we have 5 SPDX abbrevs that have multiple options in the old
Fedora abbrevs. The macro warns about that and uses the first value it founds,
which is the one that was written first in the data, so we can control the
priority by the data.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure