[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
<ijackson@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.

Reply to: