[Piuparts-devel] Pending mass bug filing for broken symlinks detected by piuparts

[Dave Steele]

On Sat, Jun 1, 2013 at 10:13 AM, Holger Levsen <holger at layer-acht.org> wrote:
> Hi,
>
> btw, I noticed "but logfile contains 'broken symlinks': 16818 passed" on
> sid-nodoc today which IMO makes this link totally useless...
>

Not 'totally'. Looking at the list, the packages look familiar. With
--fail-on-broken-symlinks, I'd expect the list to on the order of the
size of my sid list.

The resulting dependency-failed-testing list, on the other hand... But
shouldn't flagging symlinks be part of the purpose of sid-nodoc?
Fixing about three packages would bring the sid and sid-nodoc issue
lists within striking distance of each other.

I'm not proposing that sid-nodoc be considered for the d-d discussion
at this time.

> For the ones debian-devel at l.d.o agreed to have them filed as serious, I think
> failing the piuparts test is appropriate.

So we need to do something to elevate broken symlinks before the
discussion. Do we want to invoke #615034, or create a special rule for
failing /usr/lib broken symlinks?

>> > Dangling symlinks pointing to manpages or other documentation (provided
>> > by a recommded package probably even) are probably just "normal" bugs,
>> > maybe "important".
>
> I'd start with normal for now.
>

That's a given.

> And I'd do two threads on the devel list: one about some broken symlinks
> becoming serious bugs now (and mass bug filing on that) and another, about the
> mass bug filing about broken symlinks as normal bugs.
>

Ok. There will be 82 binary packages, or 66 source packages, on the
serious list, based on the /usr/lib test.

Start both threads at the same time?

Also, there may be a third case - issues I currently label as
important. Is that a sub of the second case?

>> ... and if they are resolved by the package which is calling for this
>> package to be installed, they are no more than 'normal', and so on.
>
> you mean if the broken symlink is provided by a dependend package? I dont
> think thats a bug at all then.
>

No. The target is provided by a reverse dependency, which is the
normal installation case.