Daniel P. Berrangé berrange@redhat.com writes:
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
For packages I maintain, my preference is to touch dist-git as little as possible. Ideally I would never touch dist-git at all & rather wish it didn't exist at all in its current form of spec+patchfiles.
Instead I prefer a clone of the master upstream git repo and maintain a branch with patches cherry-picked into it. This is used to auto-generate patches for the Fedora RPM, at the same time updating the patch file list in the RPM spec. The only manual step is adding the changelog entry & bumping release number.
As others have said already: this is a nice idea and I definitely would see myself using it for one package (there I have a bunch of non-upstream patches), but not for most of them, so having this as an option would be pretty cool.
BUT (and that is a very big but) this is very dangerous and makes patching just far too easy and far too tempting. If you can add a new non-upstream patch with a simple `git commit` and be done with it, then there's very little incentive to upstream these. Patching of packages *should* be hard to a certain extent, it even needs to be a PITA so that you want to get rid of that patch and upstream it. Because if you don't, you end up with hundreds of non-upstream patches that will become a huge burden down the road. (This is the worst case scenario and not something against you Daniel, but I've seen it happen already.)
Thus, unless there is some kind of additional review/check/person telling you "Stop patching downstream!", I would only allow packagers to use the source git option with FESCO's or the packaging committee's approval.