Bug#844431: Revised patch: Oppose

[Adrian Bunk]

On Wed, Aug 16, 2017 at 09:30:23AM -0700, Russ Allbery wrote:
>...
> This text is a formalization and simplification of existing practice that
> we worked out in conjuction with the reproducible builds team and that
> strikes a balance between attempting to enumerate all the causes of
> nonreproducibility (which would be quite difficult to do) and providing
> some clear guidance to maintainers about what types of output variance
> they *don't* have to worry about (since obviously packages can't be
> reproducible under all circumstances and in all environments).  The
> intention is to set a minimum bar that packages should be trying to meet,
>...

The definition of reproducibility in policy does not match any past, 
present or future practice in Debian.

And no current or currently planned reproducible testing does test
or is intended to test whether packages meet this minimum bar.

> This is directly in the center of Policy's normal role of standardizing
> and documenting best practice that has been developed elsewhere in the
> project.
>...

If it would actually standardize what is considered reproducible
in Debian everything would be fine.

> The definition is not decoupled from current practice.  It is roughly
> equivalent to the information currently captured in *.buildinfo files
> while being easily comprehensible to people who haven't studied
> *.buildinfo files.
>...

2 of the 5 items in policy require changes to .buildinfo, and for a 
third I cannot easily comprehend whether it would require changes to 
.buildinfo since it is unclear what it is supposed to mean:

- a set of environment variable values;

.buildinfo currently records only some environment variables.
If all or different ones are allowed to vary that is a change.
I am actually surprised that the latest set of suggested permitted
variations does not seem to be based on the existing list currently
used for .buildinfo

- a version of a source package unpacked at a given path;

The path is currently not in .buildinfo

- a build architecture;

What is the intended purpose of this, especially what is this supposed 
to output for i386 builds on amd64 kernel?
.buildinfo currently follows dpkg-architecture, and outputs i386.
i386/amd64 kernels is a build variation in the reproducible builds
infrastructure that does result in packages being built differently,
which makes it unclear whether this difference was supposed to be
addressed here.

> Finally, Policy in no way constrains people from filing bugs or reporting
> issues (via whatever means, such as tracker.debian.org) in packages about
> things that are not spelled out in Policy.
>...

https://tracker.debian.org/pkg/hsqldb1.8.0
"Does not build reproducibly during testing"

This statement in tracker is automatically generated based on results 
from the reproducible builds infrastructure.

Is it acceptable to claim in tracker that a package is not reproducible, 
when that package might actually be reproducible based on the definition 
of reproducibility spelled out in Policy? [1]

cu
Adrian

[1] as explained earlier, it is not obvious whether or not this
    specific package is reproducible according to Policy

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed