Re: [Piuparts-devel] Mass bug filing for shared library broken symlinks detected by piuparts
On Wed, Jul 3, 2013 at 9:04 AM, Ian Jackson
>> 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 and example
>> on the net 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
> 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).
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.