Zbyszek, thank you for your detailed feedback. I agree with you that the step to serialize patches into dist-git complicates things heavily and is error-prone. I say this as a person who wrote a ton of code [1] in packit to achieve this. Would be awesome if we could build from the git checkout instead of juggle with patches. After reading your response I feel like we agree on the fact that sources should be maintained as code in a git repo, we just don't have an agreement on how the code should be compiled into an SRPM and built in the build system. As you see in this thread, maintainers have their own preferences so there won't ever be "one way fits all". The bigger the changes we propose, the longer it will take to implement, integrate and adopt. I'm wondering if what you're proposing is affected by Packaging:SourceURL -> Git Hosting Services [2], namely "If the upstream does create tarballs you should use them as tarballs provide an easier trail for people auditing the packages." - would that imply that the "fork" is suddenly being packaged instead of the actual upstream release? [1] https://github.com/packit/packit/blob/main/packit/patches.py [2] https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services On Wed, Jun 30, 2021 at 3:46 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Wed, Jun 30, 2021 at 02:03:22PM +0200, Tomas Tomecek wrote: > > On Wed, Jun 30, 2021 at 10:40 AM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> wrote: > > > > > > > Our definition of source-git is: > > > > * upstream release tarball > > > > * downstream code changes applied as patches during %prep > > > > * additional configs for sake of building and testing > > > > > > But that describes dist-git *exactly*. Where is the difference? > > > > Upstream git history and downstream patches tracked as git commits > > instead of files. > > Hmm, so debian does something like this, with quilt for patches… > Debian-style packaging needs to do this, because they still need to > support non-git upstreams, even upstreams without version control, and > generally cater to the lowest possible denominator. > > Since source-git would be the the biggest change in Fedora packaging > in a decade, I hope we could do something better. The "source-git" > proposal as is right now tracks the patches as git commits, but > serialized. This means that the patches must be a serial sequence of > commits, so any history with merges needs to be turned into a fake > linear history. > > The current proposal also keeps the "upstream tarball" as the central > object. In the past a tarball could be a custom-crafted thing with > some pre-generated or pre-compiled stuff and files added and removed, > and the pristine checkout of a repo wouldn't build. Those times are > thankfully behind us. Tarballs are fine, but nowadays pretty much > everything is just a snapshot generated from a git repo. So we > shouldn't treat this one blob as special. A tarball generated from a > release commit is just like a tarball generated from non-tagged > commit, except that upstream designated it as special. But if the > maintainer wants/needs to build from a non-release commit, then we > should just do it. > > If we are using git, we shouldn't need to deal with applying and > removing textified patches. > > In particular, requiring a linear history quickly breaks down for > real-life repos. For example, let's say that upstream has released > version 248, does a few immediate bugfix commits, and then applies a > few spelling patches on top, and another CVE bugfix _merged_ as commit > 248+15. We want to build this as quickly as possible. > > We have two choices now: use upstream tarball and pick patches by hand > and create a linearized history. This is complex work, fraught with > potential breakage. If the merge commit had some conflicts, the > original patch from the bugfix branch will not apply. Even if there is > _no confict_, the maintainer might have applied some fixes in the > merge. So the packager needs to do a rebase of the patch and possibly > find subsequent tweaks that are not part of the patch. > > I maintain the stable branches from systemd [1], and I know firsthand > that trying to rebase non-trivial patches is complex and you just > screw it up every once in a while. And this is for a project which I > know extremely well. For a project where I'm just a packager, > non-trivial rebases become guesswork. > > The other choice is to take the appropriate upstream commit and just > build the tarball from that. Just do it, without guesswork or manual > steps. > > It feels very much like the current "source-git" proposal is trying > to recreate the existing workflows with some minimal changes. Those > existing workflows evolved to handle idiosyncrasies which are not > needed anymore. Those old projects will not switch to source-git anyway. > I think it's much better to handle those modern git upstreams > idiomatically. > > In the proposed workflow [2], 'git reset --hard' is an integral part > of the maintainer steps. I proposed how not to do that in a comment > there [3]. The important part is that how we reach the commit from > which we will build, i.e. the details of history, should be an > implementation detail. (Similarly to how normal git repos work: some > upstreams use github's "squash&merge", others use "merge" always, and > so on. We only care about the end result, i.e. the tree content of > the commit, not its parents.) > > In very short detail, the workflow IMO should be: > - take an upstream repo > > - create a branch that contains selected upstream commit + possibly > some patches + downstream packaging stuff (.spec, etc). The > tree object attached to that commit is what will be built. > > (In the common case, this branch will be a child of the upstream > release and the previous packaging branch. After all, most of the > time packaging changes when updating to a new release are very > small. This is important to be able to see (using appropriate > 'git diff' and 'git log' invocations), what changed wrt. to > the upstream, previous packaging build, latest upstream release, > etc.) > > - to build: 'git archive', unpack in the build system, go to %build. > > [1] https://github.com/systemd/systemd-stable > [2] https://pagure.io/fedora-source-git/docs/pull-request/2#request_diff > [3] https://pagure.io/fedora-source-git/docs/pull-request/2#comment-152304 > > Zbyszek > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
