Comment by MarsIronPI
2 days ago
What I've always found off-putting about the Debian packaging system is that the source lives with the packaging. I find that I prefer Ports-like systems where the packaging specifies where to fetch the source from. I find that when the source is included with the packaging, it feels more unwieldy. It also makes updating the package clumsier, because the packager has to replace the embedded source, rather than just changing which source tarball is fetched in the build recipe.
Debian requires that packages be able to be built entirely offline.
> Debian guarantees every binary package can be built from the available source packages for licensing and security reasons. For example, if your build system downloaded dependencies from an external site, the owner of the project could release a new version of that dependency with a different license. An attacker could even serve a malicious version of the dependency when the request comes from Debian's build servers. [1]
[1] https://wiki.debian.org/UpstreamGuide#:~:text=make%20V=1-,Su...
So do Gentoo and Nix, yet they have packaging separate from the source code. The source is fetched, but the build is sandboxed from the network during the configure, build and install phases. So it's technically possible.
Nix definitely does not allow most things to be built offline (at least in the way Debian means it).
With Nix, any fetcher will download the source. It does so in a way that guarantees the shasum of what is fetched is identical, and if you already have something in the nix store with that shasum, it won't have to fetch it.
However, with just a mirror of the debian source tree, you can build everything without hitting the internet. This is assuredly not true with just a mirror of nixpkgs.
6 replies →
Nix and specifically nixpkgs is IMO very bad at this. It's not a distro: it's a collection of random links that in many cases now only exists in cache.nixos.org. The tarball server frequently doesn't have content, can't represent some content at all (recursive hash types), links have rotted away completely (broadcom driver zips referencing a domain which is now advertising online gambling).
Nix isn't functional: it's a functional core that moved every bit of the imperative part to an even less parseable stage, labelled it "evaluation" and then ignored any sense of hygiene about it.
No: your dependency tree for packaging should absolutely not include an opaque binary from a cache server, or a link to a years old patch posted on someone else's bugzilla instance (frequently link rotted as well).
Nothing has made me appreciate the decisions of mainstream distributions more then dealing with an alternative like this.
3 replies →
This doesn't say what you think it does. It says that every binary package should only depend on its declared source packages. It does not say that source packages must be constructed without an upstream connection.
What the OP was referring to, is that Debian's tooling stores the upstream code along with the debian build code. There is support tooling for downloading new upstream versions (uscan) and for incorporating the upstream changes into Debian's version control (uupdate) to manage this complexity, but it does mean that Debian effectively mirrors the upstream code twice: in its source management system (mostly salsa.debian.org nowadays), and in its archive, as Debian source archives.
All that is required for this to work (building offline) and be immune to all bad thing you wrote: package build part must contain checksum of source code archive and mirror that source code.
This is such a wonderful guarantee to offer to users. In most cases, I trust the Debian maintainers more than a trust the upstream devs (especially once you take into account supply chain attacks).
It's sad how much Linux stuff is moving away from apt to systems like snap and flatpak that ship directly from upstream.
> What I've always found off-putting about the Debian packaging system is that the source lives with the packaging.
Many packages have stopped shipping the whole source and just keep the debian directory in Git.
Notable examples are
- gcc-*
- openjdk-*
- llvm-toolchain-*
and many more.
But isn't that incompatible with the proposed transition to Git?
It made a lot of sense before centralized source storage (Debian packaging predates Sourceforge, let alone github).
But it's still nice to have when an upstream source goes dark unexpectedly, as does occasionally still happen.
> I find that when the source is included with the packaging, it feels more unwieldy.
On the other hand, it makes for a far easier life when bumping compile or run time dependency versions. There's only one single source of truth providing both the application and the packaging.
It's just the same with Docker and Helm charts. So many projects insist on keeping sometimes all of them in different repositories, making change proposals an utter PITA.