Colin Watson:
> Package: debhelper
> Version: 12.7.1
> Severity: important
>
> rumur FTBFS with debhelper 12.7.1 and man-db 2.9.0-1. Running the
> binary target manually with DH_VERBOSE=1, I see the following at the
> end:
>
> [...]
>
Hi Colin,
Thanks for filing this bug.
I think you have spotted a case of (unintentional) undefined behaviour
in debhelper.
> [...]
>
> Of course, rumur could easily work around this by removing
> debian/rumur.manpages, but I assume debhelper doesn't want to create
> this kind of regression. Before man-recode existed, the net effect
> would have been that only the last of a group of files that differ only
> by compression extension is considered. For compatibility purposes, I
> think the logic in reencode_manpages will need to be adjusted to
> preserve this property.
>
> Thanks,
>
Rather, I would argue that the result is "it depends(tm)". Your
statement is true only when @manpages_to_reencode is constructed
deterministically AND when the conflicting definitions end up in the
same "parallelization bucket". However:
1) If the two conflicting definitions of the manpages end in different
buckets when calling "on_items_in_parallel", then all bets are off
and you get a standard race-condition. In best case, you get "one"
of the input files - worst case, corrupted manpages.
2) Even then, the construction of @manpages_to_reecode depends on the
order returned by filesystem (File::Find does not sort the result
readdir by default; this has to be done by the preprocess option)
3) Even if the order in 2) is stable (but not sorted), the build
putting the files there may be unstable due to parallelism.
(prior to adding parallelization in 10.2.X, we "only" suffered from 2+3)
I think the proper solution here is to either pick a "winner"
deterministically OR reject the situation as a conflict and have the
packager sort out the issue.
I am learning towards the latter as a long term solution (compat 13) and
the former as a short term (current compat levels).
Suggestions/feedback welcome.
Thanks,
~Niels
