Dne 06. 05. 20 v 13:20 Fabio Valentini napsal(a):
On Wed, May 6, 2020 at 10:37 AM Vít Ondruch
> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
>> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek <ttomecek(a)redhat.com> wrote:
>> Hi Tomas,
>> I'll respond below with some of my experiences and opinions ...
>>> Let’s talk about dist-git, as a place where we work. For us,
>>> packagers, it’s a well-known place. Yet for newcomers, it may take a
>>> while to learn all the details. Even though we operate with projects
>>> in a dist-git repository, the layout doesn’t resemble the respective
>>> upstream project.
>>> There is a multitude of tasks we tend to perform in a dist-git repo:
>>> * Bumping a release field for sake of a rebuild.
>>> * Updating to the latest upstream release.
>>> * Resolving CVEs.
>>> * Fixing bugs by…
>>> * Changing a spec file.
>>> * Pulling a commit from upstream.
>>> * Or even backporting a commit.
>>> * And more...
>>> For some tasks, the workflow is just fine and pretty straightforward.
>>> But for the other, it’s very gruesome - the moment you need to touch
>>> patch files, the horror comes in. The fact that we operate with patch
>>> files, in a git repository, is just mind-boggling to me.
>>> Luckily, we have tooling which supports the repository layout -
>>> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
>>> easily inspect the source tree or make sure your local change builds.
>>> Where am I getting with this?
>>> Over the years there have been multiple tools created to improve the
>>> development experience:
>>> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
>>> the way Fedora kernel developers work on kernel [k]).
>>> In the packit project, we work in source-git repositories. These are
>>> pretty much upstream repositories combined with Fedora downstream
>>> packaging files. An example: I recently added a project called nyancat
>>> [n] to Fedora. I have worked [w] on packaging the project in the
>>> GitHub repo and then just pushed the changes to dist-git using packit
>>> tooling. These source-git repositories can live anywhere: we have
>>> support for GitHub right now and are working on supporting pagure.
>>> Would there be an interest within the community, as opt-in, to have
>>> such source-git repositories created for respective dist-git
>>> repositories? The idea is that you would work in the source-git repo
>>> and then let packit handle synchronization with a respective dist-git
>>> repo. Our aim is to provide the contribution experience you have in
>>> GitHub when working on your packages. Dist-git would still be the
>>> authoritative source and a place where official builds are done - the
>>> source-git repo would work as a way to collaborate. We also don’t have
>>> plans right now to integrate packit into fedpkg.
>> So, in my experience, source-git might be a workable solution for
>> packages with *big* downstream modifications. However, for everything
>> else, I think it's a way to make it easy to accrue technical debt and
>> to do cargo-culting with downstream patches.
>> The vast majority of packages has *no patches* (or at most, one or two
>> of them)
> I don't really want to argue with this point, I tend to agree. Just out
> of interest, do we have some statistics to support this? O:-)
I did not have any stats when I wrote this, but now I do.
Parsing the rawhide spec files from  for lines matching
"^Patch[0-9]*:[ \t]*.*$", I get the following distribution:
number of patches: number of packages
In relative terms:
- 71% of packages have ZERO patches
- 15% have ONE patch
- 5% have TWO patches
- 3% have THREE patches
- 5% have MORE than THREE patches
Most packages have none (71%) - or at most two - patches (91%, my
original "guess" for "vast majority"), some have 3-5 patches (5%),
a minority (4%) has six patches or more. So it seems this backs up my
Thank you very much indeed!