[Reproducible-builds] Storing .deb checksums in ADMINDIR/status?

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2015-06-26 06:30:39)
> On Tue, 2015-06-23 at 09:31:05 +0200, Jérémy Bobbio wrote:
> > Some people suggested that we should record a checksum of the `.deb`
> > installed as a way to unambiguously referring to a specific package.
> 
> In principle the tuple pkgname-version-arch should be unique per
> archive, otherwise bad-things-will-happen. Of course that does not
> cover locally built packages and similar, or mixing different archives
> with duplicated tuples, but then those are probably out-of-scope for
> reproducible builds *in* Debian anyway, I guess.

I would like to second this.

During my work on real dependency solvers, we need an answer to the question
what makes a package unique and as Guillem already pointed out, a binary
package is unique if it has the same packagename-version-arch tuple.

In principal it would theoretically be possible to extend this definition by a
fourth tuple member being a checksum of some sorts but that would mean that
even more software like dpkg and apt would have to be adapted to follow this
new definition of unique-ness.

So instead of doing that I'd rather like if everybody building binary packages
that could potentially end up being mixed with Debian packages would realize
that *the name-ver-arch tuple they use for them must be unique*. If they don't
manage to do that, then somebody should make them aware of the problem that
packages are unique by the name-ver-arch tuple.

Since David pointed out that this is a real problem, I think this issue might
need more awareness.

In summary, yes this could be solved technically but I'd rather prefer a social
solution which spreads awareness about the unique-ness problem.

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150626/9091148a/attachment.sig>