[cocoafleck]

That is mostly due to the company (Docker) not doing it the usual way. Normally they should have a build server, and then have a few line install. First is to add their repository, second is to install the software. From then on you just use your normal distributions update system. (Such as for example https://software.opensuse.org/download.html?project=hardware....) The real issue is that many companies choose to not do it the right way, and instead come up with weird new installation ways. When they do the same on Windows it just works because there is only one Windows, but there are multiple Linux distributions. As Windows begins to support Arm, and Apple moves to Arm (meaning more targets to support), I suspect that currently Linux specific issues will become more universal.

[secondcoming]

Have you ever tried creating a debian package from scratch? It's not a fun experience.

[codys]

I totally agree. I'm amazed by how opaque and difficult to understand the process to create debian packages is because of all the various layers/helpers/tools that can/should be used in different cases and the difficulty in customizing things. There's a slew of interacting tooling (`dpkg`,`dpkg-buildpackage`, `debhelper`, each of the debhelper `dh-*` helpers, `sbuild`, `pbuilder`, `git-buildpackage`) that all has different documentation of varying quality, some of it replaces other pieces, etc.

My best experiences with packaging on linux have been gentoo ebuilds & arch pkgbuilds. These keep the build model pretty straight forward if the goal is to "just build a package".

That said: creating a dpkg is not an impossible thing to do. It's just more painful than it needs to be

[pxc]

1. Docker doesn't have to create anything ‘from scratch’ to package for Debian, Ubuntu, etc.— it's already in Debian

2. They are running their own apt repos already anyway! The thing the grandparent commenter is complaining about is part of normal apt usage. It's not a manual installation of some piece of Docker, just a normal part of configuring apt in order to install something that is, in fact, properly packaged.

[sofixa]

> . Docker doesn't have to create anything ‘from scratch’ to package for Debian, Ubuntu, etc.— it's already in Debian

But the version is fixed per Debian release, which means that by its EOL it will be obsolete ( it's Docker, not a database, having the latest and greatest is a huge bonus). The whole point of custom repositories is to ship independently of the OS release cycle.

[lillecarl]

This is where Flatpak and Snapcraft can help you out. Just bring all dependencies with the binaries. But then people complain that dependencies aren't up2date and how they're a security nightmare because they aren't packaged by the Debian team.

I have high hopes for Flatpak and Nix.

[pxc]

Incidentally, there is a Snap for Docker, but it's older than the one in the new Ubuntu 20.04 beta:

  snap info docker | tail 

snap-id: sLCsFAO8PKM5Z0fAKNszUOX0YASjQfeZ channels: latest/stable: 19.03.13 2021-02-12 (796) 137MB -

vs. the Ubuntu one:

  apt info docker.io 2>/dev/null | head -2

Package: docker.io Version: 20.10.2-0ubuntu2

That's the same as the version in the latest nixpkgs unstable:

  nix search nixpkgs '^docker$'                                                                                      15:41:11

* legacyPackages.x86_64-linux.docker (20.10.2) An open source project to pack, ship and run any application as a lightweight container

Also, afaict Nixpkgs doesn't expose any unit files for the Docker daemon, so it'd take a bit of monkeying around with a new package definition to expose the one from the Moby source so that you could use it on some random distro (or you could write your own). Nix doesn't currently have any system-wide module system for managing services on non-NixOS Linux, unfortunately.

[lillecarl]

Both docker and flatpak are quite new in comparision to APT. Nix isn't really new, but gained traction lately, so in comparision to APT i would say It too is "new". We're not there yet, but i i believe shipping your dependencies with your application is how it'll all pan out for a lot of things. Even if it's a security nightmare not being able to update the dependencies for the entire system.

EDIT: And being new, there facilities aren't as mature, userbase smaller, so not enough work is put into packaging the latest versions. Since they also take on the goal of sandboxing the barrier for entry might be higher.

[a-dub]

... yeah, maybe it's a mess on linux too heh. at least it's a mess you can interact with via version controllable text files and scriptable cli tools though...