If my understanding is correct, package maintainers usually directly download the source-code archives from upstream and upload it to the lookaside cache in dist-git.
But when working in a source-git context, it might make more sense, to generate those archives from the Git commit from which the downstream history starts, instead of reaching out to yet another place.
This of course would also help with consistency.
You can do that, but you have to be careful. In the instance of kernel, we do generate the source tarball from the upstream git, which is just a branch in our source-git. However, the main working branch has commits which are not upstream. In keeping with Fedora policy, and mostly because it's "The Right Thing To Do". The tarball which is uploaded to lookaside is 100% upstream, and all Fedora patches on top of that are as a separate patch. We do not want to make it difficult for anyone to see what patches we might be carrying which upstream is not.
Some projects also have dedicated scripts and require additional tools to generate upstream tarballs: cockpit requires webpack and npm: https://github.com/cockpit-project/cockpit/blob/master/Makefile.am ruby has a script written in ruby to create snapshots: https://github.com/ruby/ruby/blob/d92f09a5eea009fa28cd046e9d0eb698e3d94c5c/tool/make-snapshot
I'm wondering if some teams would like to use this way of managing sources (=generate them from source-git) without having downstream patch files.
If downstream patches exist, they are supposed to be broken out from upstream sources according to Fedora packaging policy. RHEL doesn't necessarily have this requirement, but we need to support both options.
RHEL doesn't necessarily have this requirement, but we need to support both options.
That's a little concerning as a whole, but generally shouldn't be an issue as it inherits from Fedora and usually has the split anyway...
While I do agree with you in principal, the implementation becomes more troublesome for something with a 10 year life cycle. I am pretty sure the RHEL 7 kernel would be more patch than upstream tarball at this point. That doesn't change their upstream first policy, or commitment to open source, it is just part of the overhead of providing a stable KABI, and backporting hardware support, security fixes, and bugfixes across such a lifetime.
Yeah, that's something that's specific to the RHEL kernel. Most things don't become "more patches than source" even in RHEL! :laughing:
Note to self: in some scenarios users might want control over where to get source archives from (releases vs. snapshots).
Login to comment on this ticket.