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.