Hi! While this sounds indeed interesting, I think it's impractical for at least the two reason below:
On Tue, 2017-08-15 at 09:26:24 +0200, Christian Seiler wrote: > AFAQ (Anticipated frequently asked questions): > > Q: How can you reconstruct a tarball from the installed system? Won't > that change quite a bit? How will you ever be able to get more than > just a couple of similar chunks out of this scheme? > A: If you modify stuff on your system: yes, the tarball you can > generate from that will differ from the tarball that is in the .deb. > However, as we want our .deb files to be reproducible, we are posing > additional restrictions on the tarballs inside .deb files that are > not part of the .tar standard. Most importantly the file ordering > has to be well-defined - and currently this is done via sorting in > the C locale. If we recreate the tarball from the system with these > same constrains, we should ideally get an identical tarball back if > no files are changed. Unforuntately that's not the case. Reproducible .debs are based on using the same tool versions as were used when originally generating those .deb:s. The .deb format keeps being updated, for example it changed default compressor recently-ish. I expect it will keep evolving. And what's installed on the system gives no information about what dpkg version was used to generate its original .deb. > Q: What about tools like debootstrap etc.? > A: I believe it should be possible to implement this format in > debootstrap in a relatively straight-forward manner. As Julian has mentioned, tons of things expect actual .deb packages to be around, starting with humans doing stuff like «wget URL && dpkg -i foo.deb» or dget, and tooling, etc. Thanks, Guillem
