Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 16. 11. 20 v 10:22 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote:
On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý <msuchy@xxxxxxxxxx> wrote:
Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
If you're going to have this kind of "upstream" spec file...well, I
wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec
files need to have a clear explanation that there is an "upstream" spec
file, with a justification as to why, and a link to it. At the very
top. Otherwise there is no chance any other Fedora packager is going to
find it.
This is actually a good idea. I have lots of such spec files.

Is it a good idea to document this in Packaging Guidelines?
It is already in the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity
"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, and MUST NOT overwrite those changes with
a copy from an external repository or using fedpkg import."

→ this means that in principle is OK to if a maintainer wants to keep
an "upstream" copy of the spec file, but it's their own problem to
ferry the changes back to that upstream copy. The rules only say that
they are not allowed to erase changes done by other packagers and releng.

   If upstream provides SPEC files and your SPEC is a copy you should put on top of SPEC
   file:
   # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec
But that doesn't change much. First, such a comment is not machine readable


I should not propose this, because I agree with the points bellow. But if we should have it, then:

~~~

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

~~~

would be machine readable and it would give use some idea how common this is.


Vít


But even if we apply some pattern matching, we hit the second problem: anyone
who is doing mass spec file updates (either releng or some provenpackager),
has now way to make use of this information. They are not going to
contact hundreds of upstreams to submit a cleanup fix. The only realistic
solution is what the guidelines say: it's up to the maintainer of the
package to ferry any changes back "upstream".

(More generally: what would the point of keeping an "upstream" spec
file be? Either the spec file is only used by one distro, in which
case everyone is better off if it's kept in the downstream repo. Or
it's used by multiple distros, in which case we either have an
über-complex spec file with %if-spaghetti or a spec file that doesn't
fit any distro well, and again, everyone would be better of if the
spec file were downstream.)

Zbyszek
_______________________________________________
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

Attachment: OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux