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.

▲

sillystuff 3 hours ago | parent | next [-]

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...

	▲	MarsIronPI 2 hours ago \| parent \| next [-]
		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.
	▲	0x457 2 hours ago \| parent \| prev [-]
		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.

▲

cbmuser 2 hours ago | parent | prev | next [-]

> 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.

▲

mschuster91 2 hours ago | parent | prev [-]

> 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.