[Reproducible-builds] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used

[Andreas Beckmann]

[ please keep me Cc:ed ]

Hi,

I'm just looking into reproducibility of fglrx-driver/non-free and saw
some toolchain issue resulting in unreproducible packages:


debdiff b1/amd-clinfo_15.5-2_amd64.deb b2/amd-clinfo_15.5-2_amd64.deb
(manually wrapped for better readability)

File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends:
  libc6 (>= 2.3.3),
  libgcc1 (>= 1:4.1.1),
  ocl-icd-libopencl1 | amd-libopencl1 | libopencl1,
  ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | [-libopencl-1.2-1,-]
{+libopencl-1.1-1,+}
  ocl-icd-libopencl1 (>= 1.0) | amd-libopencl1 | [-libopencl-1.1-1-]
{+libopencl-1.2-1+}


The only difference is the ordering of the dependencies generated by
dh_shlibdeps (?).

The symbols file from amd-libopencl1 that is used to generate these
dependencies makes use of alternate dependency templates and more than
one of the alternate templates are needed for the final dependencies:

===================
# <snipped some paragraphs of comments>
libOpenCL.so.1 ocl-icd-libopencl1 | #PACKAGE# #MINVER# | libopencl1
# symbols specific to this implementation - would forbid using alternate
implementations
| #PACKAGE# #MINVER#
# symbols conforming to the OpenCL standards - can use alternate
implementations
| ocl-icd-libopencl1 (>= 1.0)   | #PACKAGE# #MINVER# | libopencl-1.1-1
| ocl-icd-libopencl1 (>= 1.0)   | #PACKAGE# #MINVER# | libopencl-1.2-1
| ocl-icd-libopencl1 (>= 2.2.0) | #PACKAGE# #MINVER# | libopencl-2.0-1
# As AMD uses versioned symbols, we use this information instead of
# listing all symbols.
 (symver|optional)OPENCL_1.0 0 2
 (symver|optional)OPENCL_1.1 0 2
 (symver|optional)OPENCL_1.2 0 3
 (symver|optional)OPENCL_2.0 1:14 4
===================

Andreas

PS: As an additional reproducibility torturing measure I used the
pbuilder --twice option for the first build.

PPS: Similarly "complex" symbols files are used by ocl-icd-libopencl1
and nvidia-libopencl1, too.

PPPS: I haven't tried to see whether this unreproducibility is reproducible.