On Thu, 2020-04-16 at 13:10 +0200, Nicolas Chauvet wrote: > Le mer. 15 avr. 2020 à 13:34, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> > a écrit : > > On Wed, Apr 15, 2020 at 5:32 AM Thorsten Leemhuis < > > fedora@xxxxxxxxxxxxx> wrote: > ... > > > > There is one thing I really dislike about the scheme (one it > > > didn't > > > notice when I took a brief look at it weeks ago; sorry): There > > > are no > > > individual patches anymore in dist-git/the srpm and that afaics > > > violates > > > the packaging guidelines. > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches > > > > > > ``` > > > The files MUST then be checked into the Fedora Package revision > > > control > > > system […]. Storing the files in this way allows people to use > > > standard > > > tools to visualize the changes between revisions of the files and > > > track > > > additions and removals without a layer of indirection […]. > > > ``` > > > There are other rules in the patch section that afaics are > > > violated. > > > Were those violation discussed and blessed by the > > > Fedora Packaging Committee or FESCo? > > > > I don't think the split out patches "rule" is being violated here. > > They changed the source tarball to one generated from the git tree > > and > > they don't have any patches at the dist-git level at all. Several > > other packages in Fedora already do this, such as anaconda. > > So it means should one single line patch should be changed, you need > to re-upload a 100M tarball to the fedora lookaside cache? > I understand the benefit to have an upstream source tree as a primary > origin for kernel patch development. But what is the reason behind > this process in particular ? > > It would have been easier to only generate a full fedora diff against > the original upstream tree (using a commit-id that can also be > generated with gitlab with A PR). > Like how I expect it's done with the patch-5.7.0-redhat.patch. > > Then keep using the original upstream tarballs. (linux-M.tar.xz and > patch-M-m.xz) > I'm sure that in some cases, (minor patch update) there is even not > have to change the fedora diff. > Yes, it's a bit inefficient. I brought this up on the infrastructure list ([RFC] Optionally using git repositories instead of the lookaside cache), but people didn't seem concerned about the storage requirement. I am not particularly inspired to develop a bunch of scripts to work around the fact that we're not using git to store source code. If someone else wants to fix up the kernel build scripts I'm fine with that, although it seems to me that it's fixing the problem in the wrong place. - Jeremy _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx
