On 5/26/20 11:52 AM, Miro Hrončok wrote:
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.
Ah, makes sense.
Overall, good work!
Tomas
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.
_______________________________________________
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
