The way the specfile pulls in the latest git commit as a patch against the release tarball
is new to me. I interpretated that workflow to mean those before me thought it was
important to document all the commits that were made. That's why I did not add the
patch as a rfpkg source and instead included it with our git history.
However, if I do add the patch file as a rfpkg source per the original request, then why
bother pulling down the changes as a separate patch at all? Rpmfusion github won't
track the changes this way. Why not keep it simple and pull in one tarball that contains
Just looking to understand.
Le dim. 28 févr. 2021 à 08:08, Gary Buhrmaster
<gary.buhrmaster(a)gmail.com> a écrit :
On Sun, Feb 28, 2021 at 4:14 AM Sérgio Basto <sergio(a)serjux.com> wrote:
> Maybe we should change the guidelines.
I suspect your formal proposal will generate some
I think it will be even more relevant to compress (gz, xz, etc) the
patches from upstream
Then you can just apply them compressed, the %patch macro will deal
with the compression while applying.
The reason why I think this is revelant for lookaside is that the
patches where already applied/reviewed upstream, So having "peer
reviewing", on the rpmfusion mailing list, for any eventual other
downstream patch will be hidden or much more difficult.
rpmfusion-developers mailing list -- rpmfusion-developers(a)lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-leave(a)lists.rpmfusion.org