Control: clone -1 -2
Control: reassign -1 src:adns
Control: retitle -1 anomalous variation in symbols file
Control: reassign -2 dpkg-dev
Control: retitle -2 want stable output even when dpkg-dev makes arbitrary
choices
Guillem Jover writes ("Re: Bug#1137222: nmu: tetrinetx_1.13.16-22"):
> So the cause for this seems to stem from the adns symbols file
> containing most symbols with 1.5.0~ and a couple with 1.5.0~0
> versions.
Thanks for the investigation. This anomaly seems to have been a slip
by me in 2014. I'll fix it.
Despite this being simply a mistake in adns, I don't think we could
rule out that a packagae might reasonably end up with a symbols file
with equivalent but textually different entries. For example,
different symbols entries might be generated by different code paths
for some reason, and happen to specify equivalent but not identical
versions.
> Depending on how the symbols appear in the reverse dependency
> binaries, then the emitted versions would be either one of those.
>
> I think this should be fixed in adns, because this seems to be
> currently triggering "undefined behavior" from dpkg-dev tools.
I do think that it would be better for dpkg-dev to avoid introducing
nondeterminism when it has to choose betweeen equivalent alternatives.
(The phrase "undefined behaviour" is a red flag to me. It's from C,
which is by now rightly notorious for providing the programmer with a
hostile environment full of gotchas. I don't really think you mean
that anyway, since "undefined behaviour" might mean "delets all your
files".)
When there are multiple outputs that are conxistent with the input,
and correct, think it's fine for dpkg-dev to make an abitrary choice.
But it would be nice if the output were reproducible. That mostly
just means avoiding having it depend on randomness, time, etc.
IDK the precise dpkg-dev algorithms here, but the root of the
nondeterminism is probably perl hashes. When building packages, we
should probably disable perl's hash randomisation feature. That
exists to avoid complexity attacks; it doesn't make sense in a source
package build which can in any case execute arbitrary computations.
So perhaps something somewhere should be setting PERL_HASH_SEED=0.
> a) The tools could normalize the versions, so that versions that
> are version-wise equal, but string-wise different would not
> cause this kind of problem. This would diverge from our current
> version handling which is "preserving", and could have unintended
> fallout. I don't think this is the correct way to go.
I think this is a bad idea. The fact that two version numbers are
equal for the purposes of version comparison doesn't mean we can
substitute one for the other, in general.
I think it was probably a mistake (my mistake) to treat "0" and "00"
as equal for version comparison. That's whaat leads to the
possibility of different strings comparing equal, leading to the
distinction between textual-identicalness and equivalence. But that
ship has sailed a long time ago.
> b) The tools could start doing version-wise comparisons, and if
> the versions are equal, then do a string-wise comparison for
> sorting purposes. While this would preserve the versions and
> would solve this kind of problem, it seems rather cumbersome,
> and then we'd need to make any other tool evaluating versions
> do the same. So this does not look enticing either.
This does seem invasive, indeed.
But if we can avoid the original source of the nondeterminisim then we
could perhaps make the output unpredidtable but still stable under
rebuilds using the same inputs.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
