3 ms·

I think install time dependency resolution was a bad idea and needs to be removed entirely. Packages for package managers that do it are untestable by design, b

by matrss 2y ago

I think install time dependency resolution was a bad idea and needs to be removed entirely. Packages for package managers that do it are untestable by design, because their runtime behavior cannot be known at build time. "Functional package management", as implemented in nix and guix, is a much saner approach.

pornel 2y ago
I wish Debian/APT had first-class support for having multiple versions of the same library. On a large system it's inevitable that packages will be upgrading at different rates, and a bit of duplication can be a way out of complex system-wide dependency chains held by the most outdated package. Despite lack of tooling support, Debian still does not completely avoid duplicated packages. They merely manually move the major version number to the package name (foo v10.0 and foo11 v11.0), causing package names to vary between distros and Debian versions. This seems like the worst solution, since APT can't automatically do it where it would be useful, and renamed packages complicate use of tools like pkg-config, ansible, and providing install instructions to users.
- matrss 2y ago
  That is an orthogonal issue. Guix has first-class support for versions (where "version" means the version string of the source code), while nixpkgs uses the same naming-based approach as Debian. The important part is being able to install two packages in isolation, irrespective of if they represent the same software in different versions or if they are completely unrelated. Apt couldn't install two unrelated packages if they contain files that have the same path, to my knowledge. As soon as one foregos putting everything into a single filesystem structure (like in FHS, which most distros follow to some extent) the logical conclusion will be to prefix each packages directory with some identifier that meaningfully describes its content (which could be considered an "extended version" of this package). With nix this is a hash of all the inputs that went into the package (its own source code, compiler flags, build settings, dependencies, etc. and recursively the same for all of its dependencies). This means that if the compiler flags of e.g. a five levels deep transitive dependency are changed, then the package that depends on it changes as well, which is only reasonable since its behavior could change. At that point all dependency resolution has happened at build time and none is required at runtime. Being able to install different versions of the same package is merely a by-product of this approach.
- JackSlateur 2y ago
  One server = one feature = one library version That's the golden rule for easy upgrades, sane dependencies managements (both technicals and organisationals) There is no good reason to not spawn hundreds or thousands of VMs : just do it, make your life easier and stop bothering with a whole bunch of issues
  - JackSlateur 2y ago
    You may "booh" me. But in the end, you know I'm right : who won, the 80' era supercomputer, or the k8s/serverless world ? Yeah
bayindirh 2y ago
The thing is, Debian's solvers are always deterministic. Given from a known state, it always ends int the same state. This allows getting/setting selection lists with "dselect", and using apt for system automation feasible. In my last decade (or 15 years to be exact) with Debian, I never suffered from non-deterministic behavior or met with surprises from apt.
- matrss 2y ago
  The solver might be deterministic if you take some sufficiently large global state into account, but the process of apt install bar from a users view is not. It can have a different result depending on what is already installed, or even if all other system state is the same it can change with time. My point is that a package "bar v3.2.1" that depends on "libfoo v1.2.3" needs to be considered a different package than "bar v3.2.1" that depends on "libfoo v1.2.4" or even "libfoo v1.2.3 compiled with -O3 instead of -O2", because the resulting package can behave differently due to the variation. But as soon as you have that there is no need for install time dependency resolution anymore, since it is all done at build time.
  - rstuart4133 2y ago
    It might get better now. Packages often have dependency loops, so that "A depends on B depends on C depends on A". Autodependencies in a loop like that would never get uninstalled. One of the more obscure outcomes of that is if you later installed something else that had one of those autodepends as a less favoured alternative, it would be used regardless - ie instead of what the package you were installing said it preferred. I'm guessing this fixes that particular wart. By starting from a blank slate every time it effectively ignores those autodepend loops, so they will get uninstalled. Hallelujah.

by matrss 2y ago

pornel 2y ago

I wish Debian/APT had first-class support for having multiple versions of the same library. On a large system it's inevitable that packages will be upgrading at different rates, and a bit of duplication can be a way out of complex system-wide dependency chains held by the most outdated package. Despite lack of tooling support, Debian still does not completely avoid duplicated packages. They merely manually move the major version number to the package name (foo v10.0 and foo11 v11.0), causing package names to vary between distros and Debian versions. This seems like the worst solution, since APT can't automatically do it where it would be useful, and renamed packages complicate use of tools like pkg-config, ansible, and providing install instructions to users.

matrss 2y ago
That is an orthogonal issue. Guix has first-class support for versions (where "version" means the version string of the source code), while nixpkgs uses the same naming-based approach as Debian. The important part is being able to install two packages in isolation, irrespective of if they represent the same software in different versions or if they are completely unrelated. Apt couldn't install two unrelated packages if they contain files that have the same path, to my knowledge. As soon as one foregos putting everything into a single filesystem structure (like in FHS, which most distros follow to some extent) the logical conclusion will be to prefix each packages directory with some identifier that meaningfully describes its content (which could be considered an "extended version" of this package). With nix this is a hash of all the inputs that went into the package (its own source code, compiler flags, build settings, dependencies, etc. and recursively the same for all of its dependencies). This means that if the compiler flags of e.g. a five levels deep transitive dependency are changed, then the package that depends on it changes as well, which is only reasonable since its behavior could change. At that point all dependency resolution has happened at build time and none is required at runtime. Being able to install different versions of the same package is merely a by-product of this approach.
JackSlateur 2y ago
One server = one feature = one library version That's the golden rule for easy upgrades, sane dependencies managements (both technicals and organisationals) There is no good reason to not spawn hundreds or thousands of VMs : just do it, make your life easier and stop bothering with a whole bunch of issues
- JackSlateur 2y ago
  You may "booh" me. But in the end, you know I'm right : who won, the 80' era supercomputer, or the k8s/serverless world ? Yeah

bayindirh 2y ago

The thing is, Debian's solvers are always deterministic. Given from a known state, it always ends int the same state. This allows getting/setting selection lists with "dselect", and using apt for system automation feasible. In my last decade (or 15 years to be exact) with Debian, I never suffered from non-deterministic behavior or met with surprises from apt.

matrss 2y ago
The solver might be deterministic if you take some sufficiently large global state into account, but the process of apt install bar from a users view is not. It can have a different result depending on what is already installed, or even if all other system state is the same it can change with time. My point is that a package "bar v3.2.1" that depends on "libfoo v1.2.3" needs to be considered a different package than "bar v3.2.1" that depends on "libfoo v1.2.4" or even "libfoo v1.2.3 compiled with -O3 instead of -O2", because the resulting package can behave differently due to the variation. But as soon as you have that there is no need for install time dependency resolution anymore, since it is all done at build time.
- rstuart4133 2y ago
  It might get better now. Packages often have dependency loops, so that "A depends on B depends on C depends on A". Autodependencies in a loop like that would never get uninstalled. One of the more obscure outcomes of that is if you later installed something else that had one of those autodepends as a less favoured alternative, it would be used regardless - ie instead of what the package you were installing said it preferred. I'm guessing this fixes that particular wart. By starting from a blank slate every time it effectively ignores those autodepend loops, so they will get uninstalled. Hallelujah.