3 ms·

> jealous, insisting that every language has to conform to their way of doing things Let's ignore for a moment all your baseless assertions and focus on the fo

> jealous, insisting that every language has to conform to their way of doing things Let's ignore for a moment all your baseless assertions and focus on the following question: how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access? Is jealousy the only explanation that comes up to you?

Zyst 7y ago
Oh, check out Nix https://nixos.org/nix/ https://nixos.org/nix/ I use it for most of my dependencies, and software in OS X/Windows WSL/Linux It is a lovely environment to work with. Has completely changed how I feel about package management and the like. I know you were asking figuratively but something does happen to slot in that space.
- rumanator 7y ago
  > Oh, check out Nix Nix is a non-sequitur. Nix requires specific packages and package versions to be specified, and Nix requires the build process to be "free from side effects". That fails to address both problems stated by the OP, and actually try to reimplement what Debian's package building process already does. Other than trying to publicize Nix, your comment adds nothing to the discussion.
  - Zyst 7y ago
    >how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access? By having control over which required dependencies are downloaded. As Nix does. Why would you settle for not solving that problem? Sorry to hear you don't think my comment adds to the discussion, but I'd disagree
    - rumanator 7y ago
      > By having control over which required dependencies are downloaded. Again, Nix adds nothing to the discussion. The problem stated by the OP was caused by the (broken) way that the custom build system of a specific package was designed to work, which failed to adhere to the standard practices enforced by Debian's packaging process. If the packagers of said software project followed Debian's practices then the problem wouldn't exist. You're parroting that Nix also enables users to specify dependencies. Ok, so it works just like any other package system. What does that have to do with the problem being discussed? Nothing.
      - ertian 7y ago
        It feels like you're being unnecessarily hostile, here. He didn't address your specific problem as stated, but he did add to the discussion. I don't think it's fair to say that Nix is 'just another package manager'. It solves many of the stated problems with distro package managers (overlapping versions, user-specific packages, strict build environment rules), and provides many of the benefits of Docker and it's ilk (perfectly reproduceable environments for packages to run, including dependencies that don't fit well into traditional package managers, like JARs). Because it doesn't rely on the standard POSIX filesystem layout, it runs happily on any Linux or OSX system, alongside whatever package manager your system uses. If people started using Nix recipies instead of Docker or janky bash scripts for deployment of Hadoop and other complex software, most of this article's complaints would disappear. And Nix is, if anything, better from a sysadmin point of view than apt-style packaging systems. It makes a fine distro package manager (see: NixOS).
        rumanator 7y ago
        > It feels like you're being unnecessarily hostile, here. He didn't address your specific problem as stated, but he did add to the discussion. You're right, sorry for the tone. The thing is, it sounded an awful lot like a blatant attempt at derailing the discussion by shoehorning span to promote a build tool. Nix does not solve anything, particularly as it was being proposed as a solution to a problem that plain old Debian packages do not have. So if Nix solves nothing and Nix adds nothing to the discussion then why waste everyone's time by adding noise by selling a tool that does and solves nothing wrt plain old Debian packaging? > If people started using Nix recipies instead of Docker or janky bash scripts for deployment of Hadoop and other complex software, most of this article's complaints would disappear. ...or simply build a plain old Debian package? Is it that hard to simply follow the happy path of packaging for Debian? Why is suddenly Nix the only option on the table, specially as it brings absolutely nothing to it wrt what plain old Debian packages already provide for decades now?
  - soraminazuki 7y ago
    > That fails to address both problems stated by the OP This is wrong and unfair. One of the major problems the OP has with Docker is that many software builds are unreproducible, encouraging many people to deploy binaries of dubious quality. Nix tries to solve precisely this problem through better tooling which makes it easy to ensure that its packages are reproducible and its dependencies easily verifiable. This is also what makes Nix distinct from Debian, which tries to improve package quality through policies and community collaboration. > Nix requires the build process to be "free from side effects" I disagree that this makes Nix irrelevant to the discussion at hand. Another gripe the OP had with Docker is that it sandboxes entire apps, making it a blackbox. Nix does sandboxing on a more granular level, which provides more transparency into individual packages.
solarkraft 7y ago
Jealousy is the characterisation of exactly that behavior/aspiration to have everything managed through the OS's package manager. It's a nice effort, but for people not firmly within the ecosystem it's often a hard effort to justify to package something specifically for every distribution.
briffle 7y ago
you can use a tool like snap or appimage to pull down the newest full release of your software.. at least then, all the dependancies are 'bundled' into the image, and your not having people go randomly install crap from around the internet with no real way to update.
- throwaway2048 7y ago
  Building debian packages from source definitely does not involve "randomly installing crap from around the internet". The .sdeb format packages up sources and build scripts into one atomic, build-able unit.
  - Conan_Kudo 7y ago
    The only .sdeb archive format I know of is the one for debbuild[1]. Most Debian package build mechanisms don't have a source package archive format. [1]: https://github.com/debbuild/debbuild https://github.com/debbuild/debbuild
lmm 7y ago
Reproducible builds were a non-goal for apt for most of its existence.
- soraminazuki 7y ago
  That doesn't dismiss its immense benefits. Besides, what's the source of your claim? Package quality, ease of install, and security were always high-priority topics for Debian AFAICT.
  - lmm 7y ago
    Decades of experience using Debian. Package quality and ease of install were indeed always a priority (and security may have been claimed as one), but reproducible builds were not seen as necessary for any of those.
- rumanator 7y ago
  > Reproducible builds were a non-goal for apt for most of its existence. Your comment sounds very disingenuous, as Debian was first released in 1993 (about 26 years ago) and has been pushing for reproducible builds since 2000. https://wiki.debian.org/ReproducibleBuilds/History https://wiki.debian.org/ReproducibleBuilds/History
  - lmm 7y ago
    Your own comment is extremely disingenuous. Your own link states that there was very little enthusiasm for reproducible builds when mentioned in 2000 and 2007, and the first serious effort towards reproducible builds started in 2013.

Zyst 7y ago

Oh, check out Nix https://nixos.org/nix/ https://nixos.org/nix/ I use it for most of my dependencies, and software in OS X/Windows WSL/Linux It is a lovely environment to work with. Has completely changed how I feel about package management and the like. I know you were asking figuratively but something does happen to slot in that space.

rumanator 7y ago
> Oh, check out Nix Nix is a non-sequitur. Nix requires specific packages and package versions to be specified, and Nix requires the build process to be "free from side effects". That fails to address both problems stated by the OP, and actually try to reimplement what Debian's package building process already does. Other than trying to publicize Nix, your comment adds nothing to the discussion.
- Zyst 7y ago
  >how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access? By having control over which required dependencies are downloaded. As Nix does. Why would you settle for not solving that problem? Sorry to hear you don't think my comment adds to the discussion, but I'd disagree
  - rumanator 7y ago
    > By having control over which required dependencies are downloaded. Again, Nix adds nothing to the discussion. The problem stated by the OP was caused by the (broken) way that the custom build system of a specific package was designed to work, which failed to adhere to the standard practices enforced by Debian's packaging process. If the packagers of said software project followed Debian's practices then the problem wouldn't exist. You're parroting that Nix also enables users to specify dependencies. Ok, so it works just like any other package system. What does that have to do with the problem being discussed? Nothing.
    - ertian 7y ago
      It feels like you're being unnecessarily hostile, here. He didn't address your specific problem as stated, but he did add to the discussion. I don't think it's fair to say that Nix is 'just another package manager'. It solves many of the stated problems with distro package managers (overlapping versions, user-specific packages, strict build environment rules), and provides many of the benefits of Docker and it's ilk (perfectly reproduceable environments for packages to run, including dependencies that don't fit well into traditional package managers, like JARs). Because it doesn't rely on the standard POSIX filesystem layout, it runs happily on any Linux or OSX system, alongside whatever package manager your system uses. If people started using Nix recipies instead of Docker or janky bash scripts for deployment of Hadoop and other complex software, most of this article's complaints would disappear. And Nix is, if anything, better from a sysadmin point of view than apt-style packaging systems. It makes a fine distro package manager (see: NixOS).
      - rumanator 7y ago
        > It feels like you're being unnecessarily hostile, here. He didn't address your specific problem as stated, but he did add to the discussion. You're right, sorry for the tone. The thing is, it sounded an awful lot like a blatant attempt at derailing the discussion by shoehorning span to promote a build tool. Nix does not solve anything, particularly as it was being proposed as a solution to a problem that plain old Debian packages do not have. So if Nix solves nothing and Nix adds nothing to the discussion then why waste everyone's time by adding noise by selling a tool that does and solves nothing wrt plain old Debian packaging? > If people started using Nix recipies instead of Docker or janky bash scripts for deployment of Hadoop and other complex software, most of this article's complaints would disappear. ...or simply build a plain old Debian package? Is it that hard to simply follow the happy path of packaging for Debian? Why is suddenly Nix the only option on the table, specially as it brings absolutely nothing to it wrt what plain old Debian packages already provide for decades now?
- soraminazuki 7y ago
  > That fails to address both problems stated by the OP This is wrong and unfair. One of the major problems the OP has with Docker is that many software builds are unreproducible, encouraging many people to deploy binaries of dubious quality. Nix tries to solve precisely this problem through better tooling which makes it easy to ensure that its packages are reproducible and its dependencies easily verifiable. This is also what makes Nix distinct from Debian, which tries to improve package quality through policies and community collaboration. > Nix requires the build process to be "free from side effects" I disagree that this makes Nix irrelevant to the discussion at hand. Another gripe the OP had with Docker is that it sandboxes entire apps, making it a blackbox. Nix does sandboxing on a more granular level, which provides more transparency into individual packages.

solarkraft 7y ago

Jealousy is the characterisation of exactly that behavior/aspiration to have everything managed through the OS's package manager. It's a nice effort, but for people not firmly within the ecosystem it's often a hard effort to justify to package something specifically for every distribution.

briffle 7y ago

you can use a tool like snap or appimage to pull down the newest full release of your software.. at least then, all the dependancies are 'bundled' into the image, and your not having people go randomly install crap from around the internet with no real way to update.

throwaway2048 7y ago
Building debian packages from source definitely does not involve "randomly installing crap from around the internet". The .sdeb format packages up sources and build scripts into one atomic, build-able unit.
- Conan_Kudo 7y ago
  The only .sdeb archive format I know of is the one for debbuild[1]. Most Debian package build mechanisms don't have a source package archive format. [1]: https://github.com/debbuild/debbuild https://github.com/debbuild/debbuild

lmm 7y ago

Reproducible builds were a non-goal for apt for most of its existence.

soraminazuki 7y ago
That doesn't dismiss its immense benefits. Besides, what's the source of your claim? Package quality, ease of install, and security were always high-priority topics for Debian AFAICT.
- lmm 7y ago
  Decades of experience using Debian. Package quality and ease of install were indeed always a priority (and security may have been claimed as one), but reproducible builds were not seen as necessary for any of those.
rumanator 7y ago
> Reproducible builds were a non-goal for apt for most of its existence. Your comment sounds very disingenuous, as Debian was first released in 1993 (about 26 years ago) and has been pushing for reproducible builds since 2000. https://wiki.debian.org/ReproducibleBuilds/History https://wiki.debian.org/ReproducibleBuilds/History
- lmm 7y ago
  Your own comment is extremely disingenuous. Your own link states that there was very little enthusiasm for reproducible builds when mentioned in 2000 and 2007, and the first serious effort towards reproducible builds started in 2013.