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
