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ý <msu...@redhat.com> 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.specBut 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
