[Git][reproducible-builds/reproducible-website][master] gothenburg: Add d1-longtail.md

[Bernhard M. Wiedemann (@bmwiedemann-guest)]

Bernhard M. Wiedemann pushed to branch master at Reproducible Builds / reproducible-website


Commits:
4d2f42de by Bernhard M. Wiedemann at 2026-09-24T17:56:35+02:00
gothenburg: Add d1-longtail.md

- - - - -


1 changed file:

- + _events/gothenburg2026/agenda/d1-longtail.md


Changes:

=====================================
_events/gothenburg2026/agenda/d1-longtail.md
=====================================
@@ -0,0 +1,46 @@
+## Problem
+The Pareto principle applies to fixing r-b issues. 80% of the benefit need 20% of the work and what non-determinism remains becomes increasingly harder to make deterministic.
+
+
+In 2026, distributions such as Debian and openSUSE are already achieving 98% or 99% of reproducible packages, so the question is: what to do about the remainder?
+
+
+We would like to provide users with reproducible (more trustable) software.
+
+- users could still install non-reproducible software, what can be done about this?
+
+- For enterprise SUSE, the non-reproducible software is documented. Then a meta-package conflicts all the packages with known reproducibility issues, preventing their installation. = [https://build.opensuse.org/package/show/home:bmwiedemann/SLES-reproducible-builds](https://build.opensuse.org/package/show/home:bmwiedemann/SLES-reproducible-builds)
+
+- Another idea is that non-reproducible packages could be dropped from the main repository, and placed elsewhere
+
+- For Debian, non-reproducible packages are blocked from migrating to testing
+
+- CI runs on Debian Salsa, and this tests if things build reprodciblly (debrebuild)
+
+- repro-threshold allows checking for signatures on installation time on Debian based systems [https://github.com/kpcyrd/repro-threshold](https://github.com/kpcyrd/repro-threshold)
+
+- Is there a need to distinguish how "bad" the reproducibility issues are, e.g. just docs or build-id vs more significant differences
+
+- For GNU Guix, k of n trust of substitutes would allow users to trust substitues more (currently Guix doesn't have a mechanism for this on the client side)
+
+- Maybe APT could fallback to building from source if something is non-reproducible?
+
+- Let's add documentation to reproducible-builds.org for distributions to allow users to avoid non-reproducible software
+
+- List out known approaches to allow users to avoid the small proportion of non-reproducible software
+
+- For F-Droid, packages could be reproducible when build by F-Droid, but they could still match or not match the package provided and signed by the upstream developer.
+
+- option: get to 100% reproducible
+
+Why not have apt-transport by default in Debian:
+* added file-size in images
+* (unreproducible) python would not installable, but it required for a working OS
+* extra connections to rebuilders
+  * (unless Debian (re)distributes signed external certifications)
+  * resistance to adding more files to Debian servers
+  * property of the repository - not of the package
+
+Todo: add to _docs/long_tail.md in [https://salsa.debian.org/reproducible-builds/reproducible-website](https://salsa.debian.org/reproducible-builds/reproducible-website)
+
+link in _data/docs.yml



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/4d2f42de8543223592021775b7799d679d8a7376

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/4d2f42de8543223592021775b7799d679d8a7376
You're receiving this email because of your account on salsa.debian.org. Manage all notifications: https://salsa.debian.org/-/profile/notifications | Help: https://salsa.debian.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20260924/1facf436/attachment.htm>