3 ms·

How does Guix relate to Flatpak?

rekado 9y ago
Guix is a functional package manager, Flatpak is not. Flatpak is based on the idea of runtimes (a collection of libraries and toolchains). There is no dependency bundling with Guix and there are no "runtimes" against which binaries are deployed. Guix provides the tools for bit-reproducible builds, which is why it's used in some HPC environments (including the institute where I work).
- curiousreader 9y ago
  I read up a little on Guix, but I can't reconcile what I read with what you wrote. Guix clearly does track and even bundle dependencies. The part I'm missing is how different packages can rely on different dependencies without stepping on each others' toes. And if a certain package relies on a dependency with known vulnerabilities, do I have to wait for the package to change its dependency, or can I upgrade the dependency as soon as it issues a fix?
  - rekado 9y ago
    > Guix clearly does track and even bundle dependencies. No, it really does not. What part of the documentation made you come to this conclusion? Each package is installed into its very own prefix. The prefix is derived from the hash of all of the package's inputs. Inputs mean: the package description itself (including configure flags and the like), the package sources, and all packages it depends on, recursively. This means that every package closes over the complete directed acyclic graph of its dependencies. Change any of the inputs and the output prefix will change, i.e. the package will end up in a different, separate directory. Packages keep references to other packages. Instead of bundling all dependencies under the package's prefix, packages can reference other packages directly. We use the RUNPATH feature to embed absolute file names of e.g. libraries. A big part of Guix itself is a collection of package definitions. These definitions are just Scheme values. Taken together, these Scheme values describe a lazy graph of dependencies. Guix instantiates parts of this lazy graph when installing packages. As I wrote above, any change to a node in the graph affects all other nodes upstream of it. If there's a security fix that needs to be applied to, say, the glibc it will cause a rebuild of all packages that depend on it. (There is an optimisation called grafts, which allows us to deliver security fixes without actually rebuilding the world.) Packages that have been installed already, however, will remain untouched. To benefit from a security fix these packages have to be upgraded. Guix makes it trivial to find the users of any given package in the store, so it's easy for example to figure out if you have software that uses a vulnerable library.

Guix is a functional package manager, Flatpak is not. Flatpak is based on the idea of runtimes (a collection of libraries and toolchains). There is no dependency bundling with Guix and there are no "runtimes" against which binaries are deployed. Guix provides the tools for bit-reproducible builds, which is why it's used in some HPC environments (including the institute where I work).

curiousreader 9y ago
I read up a little on Guix, but I can't reconcile what I read with what you wrote. Guix clearly does track and even bundle dependencies. The part I'm missing is how different packages can rely on different dependencies without stepping on each others' toes. And if a certain package relies on a dependency with known vulnerabilities, do I have to wait for the package to change its dependency, or can I upgrade the dependency as soon as it issues a fix?
- rekado 9y ago
  > Guix clearly does track and even bundle dependencies. No, it really does not. What part of the documentation made you come to this conclusion? Each package is installed into its very own prefix. The prefix is derived from the hash of all of the package's inputs. Inputs mean: the package description itself (including configure flags and the like), the package sources, and all packages it depends on, recursively. This means that every package closes over the complete directed acyclic graph of its dependencies. Change any of the inputs and the output prefix will change, i.e. the package will end up in a different, separate directory. Packages keep references to other packages. Instead of bundling all dependencies under the package's prefix, packages can reference other packages directly. We use the RUNPATH feature to embed absolute file names of e.g. libraries. A big part of Guix itself is a collection of package definitions. These definitions are just Scheme values. Taken together, these Scheme values describe a lazy graph of dependencies. Guix instantiates parts of this lazy graph when installing packages. As I wrote above, any change to a node in the graph affects all other nodes upstream of it. If there's a security fix that needs to be applied to, say, the glibc it will cause a rebuild of all packages that depend on it. (There is an optimisation called grafts, which allows us to deliver security fixes without actually rebuilding the world.) Packages that have been installed already, however, will remain untouched. To benefit from a security fix these packages have to be upgraded. Guix makes it trivial to find the users of any given package in the store, so it's easy for example to figure out if you have software that uses a vulnerable library.