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

[Dave Steele]

On Fri, May 31, 2013 at 6:41 AM, Holger Levsen <holger at layer-acht.org> wrote:
> On Freitag, 31. Mai 2013, Dave Steele wrote:
>> This is worded with the assumption that the bug filing precedes the
>> failure elevation. Is that the preferred strategy?
>
> No, best to evaluate all problems before and then file bugs. A local piuparts
> instance could help you with that :)
>

Answer to the wrong question? I did use a local instance to generate
the list. The question is how broken symlinks will be represented on
p.d.o at announce time. I assume as issues.

>> One issue - I haven't found a specific policy violation to reference.
...
Does this filing notice need to be preceded by a proposed
>> change to the policy?
>
> no.

Ok, I'll proceed.

>> There are about 350 binary packages in this list, represented by just
>> under 200 maintainers.These have a total of 3800 reverse dependencies
>> that will eventually be blocked from testing if the problems are not
>> resolved. A total of 2100 broken symlinks were detected by piuparts.
>
> s#will (...) be blocked from testing#will be blocked from piuparts testing#
>

ok

>
> Also, did you mention the severity you plan to file the bugs with?
>

Yes - Important. The plan was to use

Package: <binarypackage>
Version: <version>
Severity: important
User: debian-qa at lists.debian.org
Usertags: piuparts


> Dangling symlinks pointing to manpages or other documentation (provided by a
> recommded package probably even) are probably just "normal" bugs, maybe
> "important".
>
> Other missing symlinks could be "important" or maaaaybe serious, but even I am
> not really convinced of that atm.
>

... 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.
The question is how do you apply in a reliable fashion across 2000
links? My original strategy was to go with 'important' across the
board.

>> For many of these cases, the broken symlinks occur because the target
>> of the symlink is owned by a Recommended or reverse dependency package
>> which is not yet installed. But, the failure may also indicate a
>> significant problem with the package being tested. Only by addressing
>> all of the instances can those problem cases be accurately identified.
>
> sure, but for that you need to do what Andreas suggested: provide the actuall
> missing links and categorize them.
>

Yes, the <symlinks> tag was to flag where the actual links will go,
for the bug reports.

Categorize? That could be a challenge. Let's see:

- 130 of the 350 packages have broken symlinks which all include
either /usr/share/doc or /usr/share/man. Those sound 'normal'.
- 80 have broken symlinks or targets that match
'/usr/lib/.*lib.*\.so'. Those sound 'serious', based on the first line
of Section 8, "Packages containing shared libraries must be
constructed with a little care to make sure that the shared library is
always available"
- There's not much else obvious to tease out of the 150 packages that
don't match the above. Most of the heaviest hitters fall into this
category. It seems reasonable to default to these as 'important' -
assuming "major effect on the usability of a package, without
rendering it completely unusable".

Shall I use this strategy? Any other ideas? Should I list the (2100)
symlinks and severities in the announcement? ... for all or some of
the cases? ... or list packages by "<binpkg>: <severity>"?

>
>>     A link to the log containing the indicated broken symlinks can
>>     be found on piuparts.debian.org[3]
>
> always attach a logfile.

Ok

On Fri, May 31, 2013 at 6:41 AM, Holger Levsen <holger at layer-acht.org> wrote:
> Hi Dave,
>
> first of all: thanks for insisting and going forward with this!
>
> On Freitag, 31. Mai 2013, Dave Steele wrote:
>> This is worded with the assumption that the bug filing precedes the
>> failure elevation. Is that the preferred strategy?
>
> No, best to evaluate all problems before and then file bugs. A local piuparts
> instance could help you with that :)
>
>> One issue - I haven't found a specific policy violation to reference.
>
> ouch. There is the general rule though: packages must be good citizens,
> shipping broken stuff doesnt qualify as "being a good citizen".
>
> from #debian-qa (though only asked 5min ago:)
>
> <h01ger> which part of policy prohibits broken symlinks?
> <jwilk> There's no policy about that AFAIK.
>
> (On a quick look through policy I could also find nothing)
>
>> The symlink section[1] doesn't say anything about links needing to
>> properly resolve.
>
> Thats also why mass bug filings should be discussed on debian-devel at l.d.o :)
>
>> This may lead to a couple hundred mildly perturbed
>> maintainers. Does this filing notice need to be preceded by a proposed
>> change to the policy?
>
> no.
>
>> Am I going to run into any limiting issues if I spew all of these to
>> BTS's SMTP port at once?
>
> I don't think so.
>
>> There are about 350 binary packages in this list, represented by just
>> under 200 maintainers.These have a total of 3800 reverse dependencies
>> that will eventually be blocked from testing if the problems are not
>> resolved. A total of 2100 broken symlinks were detected by piuparts.
>
> s#will (...) be blocked from testing#will be blocked from piuparts testing#
>
> else it might be confused with "entering testing (jessie)".
>
> Also, did you mention the severity you plan to file the bugs with?
>
> Dangling symlinks pointing to manpages or other documentation (provided by a
> recommded package probably even) are probably just "normal" bugs, maybe
> "important".
>
> Other missing symlinks could be "important" or maaaaybe serious, but even I am
> not really convinced of that atm.
>
>> For many of these cases, the broken symlinks occur because the target
>> of the symlink is owned by a Recommended or reverse dependency package
>> which is not yet installed. But, the failure may also indicate a
>> significant problem with the package being tested. Only by addressing
>> all of the instances can those problem cases be accurately identified.
>
> sure, but for that you need to do what Andreas suggested: provide the actuall
> missing links and categorize them.
>
>
>>     A link to the log containing the indicated broken symlinks can
>>     be found on piuparts.debian.org[3]
>
> always attach a logfile.
>
>
> cheers,
>         Holger
>
> _______________________________________________
> Piuparts-devel mailing list
> Piuparts-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/piuparts-devel