GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-08-14) - page 1 of 10
 
___________________________________________________________________
"Packages should be reproducible" added to Debian Policy
207 points by lamby
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431
___________________________________________________________________
 
k__ - 3 hours ago
maybe they should switch to Nix... wait!
 
  xorbyte - 54 minutes ago
  I think you may be confusing deterministic reproducible builds
  (that remove randomness and ensure binaries have the same content
  hash regardless of who builds them (so you can reproduce what the
  maintainers did and verify the source and binaries) to merely a
  repro'd environment where everything still works because deps are
  included, which seems to be all that Nix promises (and in fact
  there is at least one open issue to add full deterministic builds
  to Nix  https://github.com/NixOS/nixpkgs/issues/9731 )
 
  kanzure - 3 hours ago
  Migrating Debian to nix might be possible, if that was desirable.
  You could have a compatibility layer for a while, and once
  everything is using the compatibility layer (in about 200
  decades?), you deprecate the old package management details.
 
    nobodyorother - 3 hours ago
    Makes me wonder what adding Guix build support to dpkg (and
    vice-versa?) would look like, or whether it would even be
    possible in a coherent way.
 
    k__ - 3 hours ago
    I think Nix is the superior package manager, but you can
    already usw it with Debian for years now and not many people do
    it, so the problem seems to lie somewhere else...
 
      majewsky - 2 hours ago
      Two things:1. Too few marketing. I only heard of Nix for the
      first time last year.2. When you boot a virtual server, the
      UI usually offers you Debian, Ubuntu and Centos/RHEL images,
      sometimes Suse/SLES or Arch. So again, less visibility, and
      if the hoster does not allow you to bring your own image,
      it's a pain in the ass to install anything else.3. (Going off
      topic for a second: I probably would have switched to Nix(OS)
      already if it wouldn't entail effectively abandoning the
      configuration management tool that I maintain.)
 
        GlennS - 2 hours ago
        I think the marketing aspect has started to pick up
        recently. Whether through conscious effort or just word of
        mouth momentum I don't know.
 
      vertex-four - 2 hours ago
      Nix doesn't integrate with Debian well - you can also use yum
      on Debian and nobody does that either. If you're using
      Debian, it's because you want to manage a Debian system with
      Debian packages.
 
        sds2 - 1 hours ago
        Yeah, nix doesn't feel right on debian because it can't
        manage services and doesn't use the "standard" packaging
        idioms. Is there someone else with a different experience
        or a workaround?
 
    nextos - 1 hours ago
    It was discussed in the Debian mailing list long ago, when Nix
    was not so polished [1].Honestly, I think it's a migration
    really worth it. Nix (and Guix) are quite mature now. The
    advantages they bring into the table are massive.The whole
    Debian ecosystem would become a lot more integrated and robust.
    It would be possible to develop packages at their own pace,
    without having to keep all dependencies in sync with the whole
    package tree. Besides, no more dist-upgrade breaking your whole
    system. It would look a lot like a rolling release, but with
    none of its disadvantages.It would be also possible to turn all
    Debian flavours into little declarative Nix blurbs. There are
    countless advantages.[1] https://lists.debian.org/debian-
    devel/2013/02/msg00374.html
 
      throwaway2048 - 1 hours ago
      I think the risk of some software being kept on many versions
      old, full of security issues libraries is pretty significant,
      because the major impetus to force an upgrade has gone away,
      that is it wont even function without updating.
 
        flogic - 1 minutes ago
        Should this issue be addressed at a technical level or a
        policy level? No matter how they manage the distro, so
        stuff is going to come down to policy and process. To me it
        seems like the sort of thing that should be handled with
        package audits.
 
    GlennS - 2 hours ago
    I do think that Nix or something like it is the future. Or at
    least it will be if the tech community as a whole doesn't screw
    up.But I also really appreciate the massive effort that Debian
    maintainers make, and the sheer number of those
    maintainers.Combining whatever human processes Debian have in
    place to keep that going with Nix would be fantastic. Right
    now, to use Nix regularly, you really have to be willing to
    read a lot of Nixpkgs source code.Edit: I should also note that
    I do actually currently use Nix on top of Debian for my work
    machine. Servers are all NixOS machines deployed with NixOps
    though.
 
  agumonkey - 2 hours ago
  I had this reflex, but IIRC the reproducible build effort does a
  few things differently (and some more) than nix. I can't recall
  which, but there were meaningful differences.
 
gizmo686 - 4 hours ago
>Any packages that absolutely cannot be built in a reproducible
way[1] ... [1] Such as random noise added to kernel and firmware
data structures during local builds, to be used as a last defense
to avoid the herd using same keys effects, etc.Shouldn't this
example of randomness still be pushed to the installation stage,
instead of in the distribution. If Debian's binary package contains
a "random" key, then we have a pretty large herd already using it.
 
  progval - 26 minutes ago
  You don't always have randomness available at boot
 
  blcknight - 4 hours ago
  It's a last defense, it's still a smaller herd than everyone
 
  lamby - 1 minutes ago
  > pushed to the installation stage, instead of in the
  distributionIndeed. During working on reproducibility in Debian,
  I found exactly this: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=833885
 
  microcolonel - 4 hours ago
  Well even with packages like this, you could put the randomness
  in the manifest and just change it when you update the package. I
  don't see why there should be an exception for this if it's
  build-time randomness.