6 ms·

There is some nuance to this. Adding comments to the stated goal "Everyone who interacts with Debian source code (1) should be able to do so (2) entirely in gi

There is some nuance to this. Adding comments to the stated goal "Everyone who interacts with Debian source code (1) should be able to do so (2) entirely in git: (1) should be able does not imply must, people are free to continue to use whatever tools they see fit (2) Most of Debian work is of course already git-based, via Salsa [1], Debian's self-hosted GitLab instance. This is more about what is stored in git, how it relates to a source package (= what .debs are built from). For example, currently most Debian git repositories base their work in "pristine-tar" branches built from upstream tarball releases, rather than using upstream branches directly. [1]: https://salsa.debian.org https://salsa.debian.org

cryptonector 9mo ago
If "whatever tools they see fit" means "patch quilting" then please no. Leave the stone age and enter the age of modern DVCS.
- lta 9mo ago
  git can be seen as porcelain on top of patch quilting so it's not as much done âge as one might think
  - cryptonector 9mo ago
    This is a misunderstanding of what Git does. Git is a Merkle hash tree, content-addressed, immutable/append-only filesystem, with commits as objects that bind a filesystem root by its hash. The diffs that make up a commit are not really its contents -- they are computed as needed. Now most of the time it's best to think of Git as a patch quilting porcelain, but it's really more than that, and while you can get very far with the patch quilting porcelain model, at some point you need to understand that it goes deeper.
    - ongy 9mo ago
      That point is not reached during packaging though. I prefer rebasing git histories over messing with the patch quilting that debian packaging standards use(d to use). Though last I had to use the debian packaging mechanisms, I roundtripped them into git for working on them. I lost nothing during the export.
      - cryptonector 9mo ago
        Yes, I also end up doing things like that, but it's just a pain. If Debian did it themselves then adding a local commit would be truly trivial.
amluto 9mo ago
> For example, currently most Debian git repositories base their work in "pristine-tar" branches built from upstream tarball releases I really wish all the various open source packaging systems would get rid of the concept of source tarballs to the extent possible, especially when those tarballs are not sourced directly from upstream. For example: - Fedora has a “lookaside cache”, and packagers upload tarballs to it. In theory they come from git as indicated by the source rpm, but I don’t think anything verifies this. - Python packages build a source tarball. In theory, the new best practice is for a GitHub action to build the package and for a complex mess to attest that really came from GitHub Actions. - I’ve never made a Debian package, but AFAICT the maintainer kind of does whatever they want. IMO this is all absurd. If a package hosted by Fedora or Debian or PyPI or crates.io, etc claims to correspond to an upstream git commit or release, then the hosting system should build the package, from the commit or release in question plus whatever package-specific config and patches are needed, and publish that. If it stores a copy of the source, that copy should be cryptographically traceable to the commit in question, which is straightforward: the commit hash is a hash over a bunch of data including the full source!
- turminal 9mo ago
  For lots of software projects, a release tarball is not just a gzipped repo checked out at a specific commit. So this would only work for some packages.
  - zahlman 9mo ago
    If it isn't at least a gzip of a subset of the files of a specific commit of a specific repo, someone's definition of "source" would appear to need work.
    - LtWorf 9mo ago
      To get a specific commit from a repo you need to clone usually, which will involve a much bigger download than just downloading your tar file.

cryptonector 9mo ago

If "whatever tools they see fit" means "patch quilting" then please no. Leave the stone age and enter the age of modern DVCS.

lta 9mo ago
git can be seen as porcelain on top of patch quilting so it's not as much done âge as one might think
- cryptonector 9mo ago
  This is a misunderstanding of what Git does. Git is a Merkle hash tree, content-addressed, immutable/append-only filesystem, with commits as objects that bind a filesystem root by its hash. The diffs that make up a commit are not really its contents -- they are computed as needed. Now most of the time it's best to think of Git as a patch quilting porcelain, but it's really more than that, and while you can get very far with the patch quilting porcelain model, at some point you need to understand that it goes deeper.
  - ongy 9mo ago
    That point is not reached during packaging though. I prefer rebasing git histories over messing with the patch quilting that debian packaging standards use(d to use). Though last I had to use the debian packaging mechanisms, I roundtripped them into git for working on them. I lost nothing during the export.
    - cryptonector 9mo ago
      Yes, I also end up doing things like that, but it's just a pain. If Debian did it themselves then adding a local commit would be truly trivial.

amluto 9mo ago

> For example, currently most Debian git repositories base their work in "pristine-tar" branches built from upstream tarball releases I really wish all the various open source packaging systems would get rid of the concept of source tarballs to the extent possible, especially when those tarballs are not sourced directly from upstream. For example: - Fedora has a “lookaside cache”, and packagers upload tarballs to it. In theory they come from git as indicated by the source rpm, but I don’t think anything verifies this. - Python packages build a source tarball. In theory, the new best practice is for a GitHub action to build the package and for a complex mess to attest that really came from GitHub Actions. - I’ve never made a Debian package, but AFAICT the maintainer kind of does whatever they want. IMO this is all absurd. If a package hosted by Fedora or Debian or PyPI or crates.io, etc claims to correspond to an upstream git commit or release, then the hosting system should build the package, from the commit or release in question plus whatever package-specific config and patches are needed, and publish that. If it stores a copy of the source, that copy should be cryptographically traceable to the commit in question, which is straightforward: the commit hash is a hash over a bunch of data including the full source!

turminal 9mo ago
For lots of software projects, a release tarball is not just a gzipped repo checked out at a specific commit. So this would only work for some packages.
- zahlman 9mo ago
  If it isn't at least a gzip of a subset of the files of a specific commit of a specific repo, someone's definition of "source" would appear to need work.
  - LtWorf 9mo ago
    To get a specific commit from a repo you need to clone usually, which will involve a much bigger download than just downloading your tar file.