Le samedi 16 mai 2020 à 11:09 +0200, Nicolas Mailhot a écrit : > Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit : > > So, another way that could work, with minimal tooling is that we > > keep > > the master branch strictly mirroring whatever upstream branch we > > follow, > > For some projects we are not hopping between branches of the same > upstream git, we are hopping between branches in different forked > repos of the same upstream To expand a little: when you are creating a Fedora package, you are packaging a fixed code state (and the state must stay fixed for trivial reproducibility, auditing, and security reasons). In git speak that means you are packaging a specific commit reference, that may (if upstream is careful and serious) be tagged with a clean fixed version string. That means packaging a branch is a no-go. It’s not a fixed git reference, it’s a moving reference. *How* upstream arrived to this fixed state from the last packaged fixed state is deeply uninteresting from the srpm POW. It may not even exist as clean git history upstream (assuming upstream uses git). For exemple, you package foo project, it gets in governance trouble and the original repository is no longuer updated, so you bet on fork foo1, that seems to have picked up the dev. Six months later you lost your bet, devs have consolidated on foo2 fork. There is no clean upstream git history from foo1 to foo2, foo1 is a dead evolutionary path. Also there may even be a complete state tracking hole somewhere in the middle, because the creator of foo2 did not bother importing foo history in its own repo, and did some private dev starting from a partial copy of some (reformatted/reprocessed) foo files. Having needed to reconstitute fragmentary dev history in a new consolidated upstream git, I can tell you splicing past repo history fragments is non- trivial. I can totally understand why some upstreams do not bother with it after a governance accident. Therefore, all the systems that try to base a Fedora package history on the mirorring of a unified unchanging monotonic upstream repo are broken by construction. The only thing you can reliably import in Fedora land are specific hashes or tags. And the upstream repo where you can find those hashes or tags may change over time. I suppose you *could* ask a downstream Fedora scm “mirror” to compute a git path from the last packaged state to the new one, faking a merge of the new state over the last state, and faking continuous regular upstream history. But why bother? You’d be creating artificial git history complexity that will exist Fedora-side only, and that upstream will not understand and disagree with, just to avoid cloning the upstream repo of the day separately to make your changes and PRs there. Also, rpm is able to package multiple source archives in a single spec, and we have packagers that make use of this capability. If you wanted a fully working scm mirroring system, not only would you need to fake continuity between upstream scm repositories that do not provide this continuity, but to merge multiple upstream scm repositories in a single downstream git (good luck producing patches that upstream will accept from this unified repository). In the meanwhile, you could just dump in your spec file %global forgeurl0 https://repo0 %global commit0 hash0 # repo0 time handling is broken %global time0 2020-05-16T12:25:43+00:00 %global forgeurl1 https://repo1 %global tag1 x.y.z %global forgepatchlist1 %{expand: foo1X.patch foo2X.patch } %forgemeta %sourcelist %forgesources %patchlist %forgepatches … %setup %forgesetup and be done. All existing Fedora tools like spectool will work just fine on that (actually the forge macros are not quite there yet in the version included in redhat-rpm-config, I still need to upstream multipatch handling once I finish QAing it) Regards, -- Nicolas Mailhot _______________________________________________ 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
