[Piuparts-devel] Mass bug filing for shared library broken symlinks detected by piuparts

[Dave Steele]

On Wed, Jul 3, 2013 at 9:04 AM, Ian Jackson
<ijackson at chiark.greenend.org.uk> wrote:
>> Shortly, piuparts.debian.org will be elevating the broken symlink test
>> in sid from a warning to an error status. In advance of that, bugs
>> submissions are planned against packages which are responsible for
>> such links.
>
> I don't think this is a good idea.
>
>>     These are sometimes triggered because a Recommended or reverse
>>     dependency package owning the symlink target file is not yet
>>     installed. This type of failure mode needs to be eliminated so
>>     that other symlink problems become more visible. In this case,
>>     the problem can be resolved by creating a trigger for the
>>     target file. See the dpkg triggers documentation[1] and example
>>     on the net[2] for implementation details.
>
> I think this should be dealt with by making the diagnosis more
> sophisticated, not by introducing substantial additional complexity
> into packages.  Alternatively, you should implement an override
> facility.
>
> There is IMO nothing wrong with package X containing a symlink to a
> file present in Y, if there is some plausible explanation and the
> broken link doesn't cause harmful behaviour on the user's system.
>
> If X recommends (or even suggests) Y this probably means that there is
> such an explanation, but it seems to me that this situation might
> occur even if there is no declared relationship between X and Y (for
> example, one of the packages might contain a plugin for the other,
> implemented by dropping a symlink into an appropriate directory).
>
> Ian.
>

Ok, here is my case. In short:

- My read of the Policy says that broken shared library symlinks
represent a violation.

- The 'override facility' would be problematic. The reliability of an
automated facility would be suspect (there is a reason that there is a
piuparts 'dependency-failed-testing' state instead of an automated
means to compensate for dependency failures). A manual facility
implies inspection of every release of affected packages.

- In either case, an explanation of, for instance, link X->Y is
resolved by installing Recommended package Z doesn't IMO answer the
question of whether or not the breakage is benign. Piuparts.d.o is the
wrong place to place this responsibility.

- IMO, creating broken symlinks is a bad practice.

The piuparts broken symlink test can find significant problems in
packages. For the test to be useful, the issues it finds need to be
addressed at the source.