In general, I disagree with the premise that anyone needs to care there's an upstream spec file. The burden should be on the maintainers if they want to provide this sort of thing. And I'm saying that as someone who maintains spec files in projects both upstream and downstream in Fedora.

I fundamentally disagree with a concept of "upstream specfile". Specfile is a recipe for downstream to package an upstream project.

But even if I disregard that for the sake of an argument, I don't think that this information needs to be distributed to our users via a provide.

I don't know about any use of Provides: that would similarly be specified
in spec file but eventually wasn't provided by the binary package.
I mean, it isn't IMO semantically correct to specify such provides as long
as the spec file really isn't shipped in RPM payload. Maybe if we found a
way to have the Provides in source RPM...

I think this duplicate of:

If some maintainers are also attempting to keep copies of a spec in an outside repository, they MUST be prepared to merge changes made to the spec in Fedora's repository

I fundamentally disagree with a concept of "upstream specfile". Specfile is a recipe for downstream to package an upstream project.

+1

But even if I disregard that for the sake of an argument, I don't think that this information needs to be distributed to our users via a provide.

We can filter them out during build, right? :)

I admit that I just don't see the point in this. We already specify that the specfile within the Fedora git repo is the canonical one just above this patch. I'm not sure what useful functionality is enabled by the Provide:, and I don't see how the other text isn't just a restatement of the existing text.

We already specify that the specfile within the Fedora git repo is the canonical one

It is canonical for Fedora, but may not be primary source for the maintainer. E.g., https://github.com/rpm-software-management/mock/blob/master/mock/mock.spec

But these are the Fedora packaging guidelines; the primary source from Fedora's perspective is defined to be what is in Fedora git. Maintainers that want to attempt to do something different get to figure out how to do this. The existing text of the guidelines already makes this explicit.

How is this better than just having a comment? I know the email thread mentioned being machine readable, but why does that matter for this?

Furthermore, the issue in the thread was that the proven packager ignored the "should" guideline of communicating with the maintainer. I don't see how a provides (or a comment) would have changed that.

How is this better than just having a comment? I know the email thread mentioned being machine readable, but why does that matter for this?

I think that it would be nice to understand how widely are used the upstream .spec files. Comments won't cut that.

How is this better than just having a comment? I know the email thread mentioned being machine readable, but why does that matter for this?

I think that it would be nice to understand how widely are used the upstream .spec files. Comments won't cut that.

And in theory, doing mass changes, it might also allow to warn the maintainers in advance, therefore improve the communication.

When doing mass changes, the communication is en masse, hence a new provide won't affect it in any way. What am I not getting?

We talked about this at this weeks meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-11-19/fpc.2020-11-19-17.00.txt

When doing mass changes, the communication is en masse, hence a new provide won't affect it in any way. What am I not getting?

This allow your communication be more targeted, i.e. communicate better.

This allow your communication be more targeted, i.e. communicate better.

Suppose I write an email to the devel list about my mass change.
Suppose I Bcc all the affected package maintainers.

For example: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PQIGCQCRNBYNXBX2ICWEM3PLDLNOG2ZT/

I don't really understated how would I be expected to use this:

Provides: upstream-spec(https://some.url/to/upstream/package.spec)

...to target my communication better? Let's say I find 20 of those in the affected packages set. Am I expected to go to https://some.url/to/upstream/package.spec and figure out how to push my change there as well? Even if some.url is a known platform (e.g. github), it is not reasonable to expect me to go and create 20 pull requests -- I plan to change Fedora spec files, not some upstream specfiles I know nothing about.

E.g. do the spec files in upstream also support platforms that don't have the %{python3_version_nodots} macro defined? Or are upstream spec files actually just templates to be fully rendered by some other tooling I know nothing about?

Let's say I find 20 of those in the affected packages set. Am I expected to go to https://some.url/to/upstream/package.spec and figure out how to push my change there as well?

I don't think that anybody said that. But so far, you are not able to figure out that URL even if you want to do that.

Even if some.url is a known platform (e.g. github), it is not reasonable to expect me to go and create 20 pull requests -- I plan to change Fedora spec files, not some upstream specfiles I know nothing about.

Yes, right, so far you have only option to change the Fedora specs, because you know nothing about the upstream specs. That is the point.

E.g. do the spec files in upstream also support platforms that don't have the %{python3_version_nodots} macro defined? Or are upstream spec files actually just templates to be fully rendered by some other tooling I know nothing about?

Sorry, but this is complete OT here, because these questions applies no matter if the .spec is just in Fedora or it is also somewhere else.

When the spec file is in Fedora, I know I am editing it for Fedora. When the spec file is in upstream, I know nothing.

Either way, if package maintainers choose to keep an upstreams copy/variant of the specfile (presumably because they are both downstream and upstream maintainers like with mock or abrt), they do it to make their life easier but they need to be prepared that others don't follow their work flow. And I believe that by standardizing a way of saying "this spec file is maintained elsewhere" we are standardizing the practice of doing that. Hence I rather not.