On 26. 05. 20 11:29, Tomas Orsava wrote:
On 5/25/20 7:42 PM, Miro Hrončok wrote:
On 25. 05. 20 18:33, Tomas Orsava wrote:
On 4/19/20 4:55 PM, Miro Hrončok wrote:
4) Make it so that for given arguments, the macro will only expand to
something once per build. Hence when you use it with package name, the
automatic provides won't re-add the same provide again. This also means you
cannot have 2 different (sub)packages provide the same name-version-release,
but that shall be very very very uncommon need and can always be
workarounded somehow if needed.
I thought multiple identical provides were just unified and didn't pose a
problem. So what is the reason to focus on this once-per-build expansion?
Not if one if manual and one from a generator. See:
https://github.com/rpm-software-management/rpm/issues/1166
Interesting. One thing not mentioned is, does this cause any issues besides the
visual issue of the provide being listed twice?
Technical issues? No. Createrepo merges those, so in the repo, no difference.
But rpmlint is very loud about those. It tells you: This provide you put in is
not needed (which is great except it only applies to rawhide and we don't want
packagers start removing it and merging the removal to older branches).
Side note: Once Fedora 32 goes EOL, we can change the behavior, so rpmlint
starts bugging packagers about this again.
7) Support arbitrary names. Only provide the given name and nothing else if
not "recognized".
Given the limitations, I agree with this choice.
What limitations?
I was referring to this bit from the other thread:
> we cannot error out with arbitrary package names, so we currently need to
pre-filter the arguments before using them
Did I misunderstand it?
Not really. I did. Nothing to discuss here, these aren't the droids you're
looking for... move along.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
