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

[Andreas Beckmann]

On 2013-06-03 05:40, Dave Steele wrote:
> On Sun, Jun 2, 2013 at 6:08 PM, Andreas Beckmann <anbe at debian.org> wrote:
>> On 2013-06-02 20:26, Dave Steele wrote:
>>
>> I don't think Recommends are a useful relation for -dev packages, for
>> the 2 packages I looked at this is clearly a missing Depends.

> That is a set of reasoning that can/should be assigned to the maintainer.

Or to the d-d discussion. So far I didn't see a use case for Recommends:
libfoo0 instead of Depends: libfoo0 in libfoo-dev.
May even need a policy clarification :-)

>>> Otherwise, we may have a flat out disagreement here.
>>> ...The bug filing does not need to have a requirement to go
>>> into further analysis of the mechanism of the breakage, or to point to
>>> the particular related package involved with the problem (if there is
>>> one), ...

Writing good bug reports helps getting them fixed faster :-)
Having a good subject may prevent reporting duplicates.
  Subject: $pkg: Broken .so symlink due to missing Depends: $dep
contains several more possible search terms

> The real exercise is turning that into actionable information, that is
> worth the cost.

attached a script and a csv with the following columns appended:
(only containing the .*-dev,.*.so,.* entries)
* resolved link target (for grepping in Contents)
* package containing that file (may be empty)
* direct relationship to that package (if any, only Recommends/Suggests)

interesting are the ones that don't have a package providing the file,
these may require more investigation

BTW, it would be nice to have the binary package version included in the
.csv/spreadsheet for easy checking whether this may be an outdated report.

> The value of the automation would be to establish categorization for
> purposes of setting severity. I question how knowing the package(s)
> owning the target helps all that much. Maybe you can suss out, if it
> is not a Depends, Recommends et al or recursive rdep (accounting
> 'properly' for dependency loops), that there is a missing Depends
> situation. I simply don't think it is worth the effort. I doubt there
> are many of these, the cost of undershooting severity is small vs.
> going through the calculation, and the maintainer should already know
> what package the target belongs to, and what its role should be.

I'm not sure how to subcategorize the current set of *-dev *.so broken
links.

>>>> And for filing a serious bug, a manual inspection of the package should
>>>> be made, and as a result we should be able to mention the missing
>>>> dependency in this case.
>>>
>>> Disagree. I think we can trust that piuparts identified the right
>>> package, for cases in sid-fail-broken-symlinks where the broken
>>> symlink appears only once, and also that it is not a requirement to
>>> identify the missing dependency/reverse dependency/recommends in the
>>> bug filing.

You need to inspect the packages manually anyway to see whether there is
already a bug filed to avoid reporting duplicates.
At least libjson* already has (several) reports w.r.t. such a broken link.

>> maybe we should verify the documentation related ones with
>> --install-recommends

> To what end? Documentation cases are already 'normal' severity. Tying
> or not tying to a Recommends doesn't change that.

I just switched my sid-bl instance to do --install-recommends, lets see
how the numbers change.

If a broken link is fixed by installing Recommends, this is a less
serious problem, especially for documentation.
But having a few packages fixed that way will allow us to test more
packages to find the worse ones :-)

> Ok, enough talking. So we are butting heads, and again it is about
> scope. All of this concerns where the line is between the filer's
> responsibility, and the maintainer's. The issue is precluding progress
> on any other front. If history is a guide, further discussion will not
> be fruitful.

> So, let me ask for a clear statement from you. What, out of all of the
> above, do you consider a requirement, and what is just us going around
> about?

* get bugs filed for the identified anomalies (usr/bin, xmanpages-ja,
buildd paths (searchmonkey, libaudiomask-dev), ${DEB_HOST_MULTIARCH})

For getting the broken-so-symlink-in-dev-package MBF going:
* filter out bugged packages from the list of candidates, include a
count/list of packages that already have bugs filed for d-d
* prepare an announcement and template, 80+ packages is a good start for
a MBF

* bugs should be filed for binary packages
* if there is more than one buggy binary package per source, merge them
into one report, these are very similar problems and should be fixed in
one go; use syntax
  Package: pkg1,pkg2,...

For getting the maintainer list use the output from dd-list (seems to
take both source and binary packages) on the list of packages where you
plan to file bugs.


Andreas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: resolve-broken-links
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20130603/945a99ee/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dev-so-resolved.csv.gz
Type: application/x-gzip
Size: 5802 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20130603/945a99ee/attachment-0001.bin>