6 ms·

The whole patch quilting thing is awful. Just keep the patches as commits. It won't "trick" me or anyone else, especially if you keep them in branches that de

The whole patch quilting thing is awful. Just keep the patches as commits. It won't "trick" me or anyone else, especially if you keep them in branches that denote "debian". Please, please, stop the nonsense with the patch quilting -- it's really cumbersome, it adds unnecessary cognitive load, it raises the bar to contributions, it makes maintenance harder, and it adds _zero value_. Patch quilting is a lose-lose proposition.

dima55 10mo ago
Moving from a patch stack maintained by quilt to git is what this article is about.
IshKebab 10mo ago
What is patch quilting, for the blissfully unaware?
- eichin 10mo ago
  https://wiki.debian.org/UsingQuilt https://wiki.debian.org/UsingQuilt but the short form is that you keep the original sources untouched, then as part of building the package, you apply everything in a `debian/patches` directory, do the build, and then revert them. Sort of an extreme version of "clearly labelled changes" - but tedious to work with since you need to apply, change and test, then stuff the changes back into diff form (the quilt tool uses a push/pop mechanism, so this isn't entirely mad.)
  - IshKebab 10mo ago
    Ha yes that does sound mad. If only there was a version control system specifically designed to track changes to code...
    - blibble 10mo ago
      it's quite difficult to maintain a quilt like workflow with plain git I've tried it
      - cryptonector 10mo ago
        Quilt is difficult to maintain, but a quilt-like workflow? Easy: it's just a branch with all patches as commits. You can re-apply those to new releases of the upstream by using `git rebase --onto $new_upstream_commit_tag_or_branch`.
        coryrc 10mo ago
        Those who don't understand git are doomed to reimplement half of it poorly? (I know that's not quite the Greenspun quote)
        cryptonector 10mo ago
        I think that's right, sadly.
        mxey 10mo ago
        How do you track changes to the patches themselves?
        IshKebab 10mo ago
        You can keep the old branches around if you want. Or merge instead of rebasing.
        cryptonector 10mo ago
        By having a naming convention for your tags and branches, then you can always identify the upstream "base" upon which the Debian "patches" are based, and then you can trivially use `git log` to list them. Really, Git has a solution to this. If you insist that it doesn't without looking, you'll just keep re-inventing the wheel badly.
    - db48x 10mo ago
      Quilt predates Git. Back then source was distributed as a tarball, and Debian simply maintained a directory full of patches to apply to the tarball.
      - IshKebab 10mo ago
        Sure but Git has been available (and super popular) for almost 20 years now.
        tremon 10mo ago
        So has git-buildpackage; the debian historical archives don't go further back than v0.4, but the oldest bug report referencing gbp is from december 2006: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987
        db48x 10mo ago
        Yea, so? Debian goes back 32 or more years, and quilt dates to approximately the same time. It’s probably just a year or two younger than Debian. At Mozilla some developers used quilt for local development back when the Mozilla Suite source code was kept in a CVS repository. CVS had terrible support for branches. Creating a branch required writing to each individual ,v file on the server (and there was one for every file that had existed in the repository, plus more for the ones that had been deleted). It was so slow that it basically prevented anyone from committing anything for hours while it happened (because otherwise the branch wouldn’t necessarily get a consistent set of versions across the commit), so feature branches were effectively impossible. Instead, some developers used quilt to make stacks of patches that they shared amongst their group when they were working on larger features. Personally I didn’t really see the benefit back then. I was only just starting my career, fresh out of university, and hadn’t actually worked on any features large enough to require months of work, multiple rounds of review, or even multiple smaller commits that you would rebase and apply fixups to. All I could see back then were the hoops that those guys were jumping through. The hoops were real, but so were the benefits.
        10mo ago
lta 10mo ago
It's worth mentioning the quilting approach likely predates the advent of git by at least a decade.. I think compatibility with git has been available for a while now and I assume there was always something more pressing than migrating the base stack to git
- XorNot 10mo ago
  dgit handles the whole affair with very little fuss I've found and is quite a pleasant workflow.
  - cryptonector 10mo ago
    What is dgit?
    - RandallBrown 10mo ago
      https://wiki.debian.org/DgitFAQ https://wiki.debian.org/DgitFAQ
      - cryptonector 10mo ago
        Thanks! IMO Debian should just switch to only Git.
m463 10mo ago
> 4. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control.
gioele 10mo ago
> The whole patch quilting thing is awful. Just keep the patches as commits. I'd say that `quilt` the utility is pretty much abandoned at this point. The name `quilt` remains in the format name, but otherwise is not relevant. Nowadays people that maintain patches do it via `gbp-pq` (the "patch queue" subcommand of the badly named `git-buildpackage` software). `gbp-pq switch` reads the patches stored in `debian/patches/`, creates an ephemeral branch on top of the HEAD, and replays them there. Any change done to this branch (new commits, removed comments, amended commits) are transformed by `gbp-pq export` into a valid set of patches that replaces `debian/patches/`. This mechanism introduces two extra commands (one to "enter" and one to "exit" the patch-applied view) but it allows Debian to easily maintain a mergeable Git repo with floating patches on top of the upstream sources. That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian.
- coryrc 10mo ago
  > That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian Rebase.
  - coryrc 10mo ago
    Also rebasing has less information available to it, so it's less likely to update cleanly than merging. Don't do it!! Just consider the diff between the new head and upstream as "the diff" and describe the reasons for it.
    - cryptonector 10mo ago
      What, no. In a merge you have two parents and their histories. In a rebase you have... the same thing as-if you had merged a fast-forward-ready branch. It's the same thing. If you insist you can add Merge commits to bracket fast-forward pushes, but arguably there is no need, and especially so for something like Debian packages where the convention would be that Debian's patches are "always on top", so you can see them by doing `git log ${base}..${debian_release_branch}` for any release. (And what's the base? Whatever upstream branch/tag the Debian release is based on, but you can add more tags with a Debian naming convention to denote the bases.)
deleted 10mo ago
[deleted]
blucaz 10mo ago
Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does. For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. For example to see how glibc is currently customized in debian testing/unstable you can just navigate this webpage: https://sources.debian.org/src/glibc/2.42-6/debian/patches https://sources.debian.org/src/glibc/2.42-6/debian/patches If everything gets merged in the same git tree it's way harder. Harder but doable with a rebase+force push workflow, which makes collaboration way harder. Just impossible with a merge workflow. As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened. In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through.
- cryptonector 10mo ago
  > For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. How is this not also true for Git? Just put all the Debian commits "on top" and use an appropriate naming convention for your branches and tags. > If everything gets merged in the same git tree it's way harder. Yes, so don't merge, just rebase. > Harder but doable with a rebase+force push workflow, which makes collaboration way harder. No force pushes, just use new branch/tag names for new releases. > Just impossible with a merge workflow. Not impossible but dumb. Don't use merge workflows! > As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened. Git with a suitable web front-end gives you exactly that. > In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through. `git format-patch` and related can do the moral equivalent.
deleted 10mo ago
[deleted]

dima55 10mo ago

Moving from a patch stack maintained by quilt to git is what this article is about.

IshKebab 10mo ago

What is patch quilting, for the blissfully unaware?

eichin 10mo ago
https://wiki.debian.org/UsingQuilt https://wiki.debian.org/UsingQuilt but the short form is that you keep the original sources untouched, then as part of building the package, you apply everything in a `debian/patches` directory, do the build, and then revert them. Sort of an extreme version of "clearly labelled changes" - but tedious to work with since you need to apply, change and test, then stuff the changes back into diff form (the quilt tool uses a push/pop mechanism, so this isn't entirely mad.)
- IshKebab 10mo ago
  Ha yes that does sound mad. If only there was a version control system specifically designed to track changes to code...
  - blibble 10mo ago
    it's quite difficult to maintain a quilt like workflow with plain git I've tried it
    - cryptonector 10mo ago
      Quilt is difficult to maintain, but a quilt-like workflow? Easy: it's just a branch with all patches as commits. You can re-apply those to new releases of the upstream by using `git rebase --onto $new_upstream_commit_tag_or_branch`.
      - coryrc 10mo ago
        Those who don't understand git are doomed to reimplement half of it poorly? (I know that's not quite the Greenspun quote)
        cryptonector 10mo ago
        I think that's right, sadly.
      - mxey 10mo ago
        How do you track changes to the patches themselves?
        IshKebab 10mo ago
        You can keep the old branches around if you want. Or merge instead of rebasing.
        cryptonector 10mo ago
        By having a naming convention for your tags and branches, then you can always identify the upstream "base" upon which the Debian "patches" are based, and then you can trivially use `git log` to list them. Really, Git has a solution to this. If you insist that it doesn't without looking, you'll just keep re-inventing the wheel badly.
  - db48x 10mo ago
    Quilt predates Git. Back then source was distributed as a tarball, and Debian simply maintained a directory full of patches to apply to the tarball.
    - IshKebab 10mo ago
      Sure but Git has been available (and super popular) for almost 20 years now.
      - tremon 10mo ago
        So has git-buildpackage; the debian historical archives don't go further back than v0.4, but the oldest bug report referencing gbp is from december 2006: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987
      - db48x 10mo ago
        Yea, so? Debian goes back 32 or more years, and quilt dates to approximately the same time. It’s probably just a year or two younger than Debian. At Mozilla some developers used quilt for local development back when the Mozilla Suite source code was kept in a CVS repository. CVS had terrible support for branches. Creating a branch required writing to each individual ,v file on the server (and there was one for every file that had existed in the repository, plus more for the ones that had been deleted). It was so slow that it basically prevented anyone from committing anything for hours while it happened (because otherwise the branch wouldn’t necessarily get a consistent set of versions across the commit), so feature branches were effectively impossible. Instead, some developers used quilt to make stacks of patches that they shared amongst their group when they were working on larger features. Personally I didn’t really see the benefit back then. I was only just starting my career, fresh out of university, and hadn’t actually worked on any features large enough to require months of work, multiple rounds of review, or even multiple smaller commits that you would rebase and apply fixups to. All I could see back then were the hoops that those guys were jumping through. The hoops were real, but so were the benefits.
        10mo ago

lta 10mo ago

It's worth mentioning the quilting approach likely predates the advent of git by at least a decade.. I think compatibility with git has been available for a while now and I assume there was always something more pressing than migrating the base stack to git

XorNot 10mo ago
dgit handles the whole affair with very little fuss I've found and is quite a pleasant workflow.
- cryptonector 10mo ago
  What is dgit?
  - RandallBrown 10mo ago
    https://wiki.debian.org/DgitFAQ https://wiki.debian.org/DgitFAQ
    - cryptonector 10mo ago
      Thanks! IMO Debian should just switch to only Git.

m463 10mo ago

> 4. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control.

gioele 10mo ago

> The whole patch quilting thing is awful. Just keep the patches as commits. I'd say that `quilt` the utility is pretty much abandoned at this point. The name `quilt` remains in the format name, but otherwise is not relevant. Nowadays people that maintain patches do it via `gbp-pq` (the "patch queue" subcommand of the badly named `git-buildpackage` software). `gbp-pq switch` reads the patches stored in `debian/patches/`, creates an ephemeral branch on top of the HEAD, and replays them there. Any change done to this branch (new commits, removed comments, amended commits) are transformed by `gbp-pq export` into a valid set of patches that replaces `debian/patches/`. This mechanism introduces two extra commands (one to "enter" and one to "exit" the patch-applied view) but it allows Debian to easily maintain a mergeable Git repo with floating patches on top of the upstream sources. That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian.

coryrc 10mo ago
> That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian Rebase.
- coryrc 10mo ago
  Also rebasing has less information available to it, so it's less likely to update cleanly than merging. Don't do it!! Just consider the diff between the new head and upstream as "the diff" and describe the reasons for it.
  - cryptonector 10mo ago
    What, no. In a merge you have two parents and their histories. In a rebase you have... the same thing as-if you had merged a fast-forward-ready branch. It's the same thing. If you insist you can add Merge commits to bracket fast-forward pushes, but arguably there is no need, and especially so for something like Debian packages where the convention would be that Debian's patches are "always on top", so you can see them by doing `git log ${base}..${debian_release_branch}` for any release. (And what's the base? Whatever upstream branch/tag the Debian release is based on, but you can add more tags with a Debian naming convention to denote the bases.)

deleted 10mo ago

[deleted]

blucaz 10mo ago

Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does. For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. For example to see how glibc is currently customized in debian testing/unstable you can just navigate this webpage: https://sources.debian.org/src/glibc/2.42-6/debian/patches https://sources.debian.org/src/glibc/2.42-6/debian/patches If everything gets merged in the same git tree it's way harder. Harder but doable with a rebase+force push workflow, which makes collaboration way harder. Just impossible with a merge workflow. As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened. In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through.

cryptonector 10mo ago
> For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. How is this not also true for Git? Just put all the Debian commits "on top" and use an appropriate naming convention for your branches and tags. > If everything gets merged in the same git tree it's way harder. Yes, so don't merge, just rebase. > Harder but doable with a rebase+force push workflow, which makes collaboration way harder. No force pushes, just use new branch/tag names for new releases. > Just impossible with a merge workflow. Not impossible but dumb. Don't use merge workflows! > As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened. Git with a suitable web front-end gives you exactly that. > In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through. `git format-patch` and related can do the moral equivalent.

deleted 10mo ago

[deleted]