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

[Dave Steele]

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.

>> 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), ...
>
> since you know the broken symlink, you know the expected target file and
> can look this up in the Contents file
>
> ...
> Using perl+sed for parsing the .csv and using a sh loop over all broken
> links is left as an excercise to the reader.

Please try to avoid a patronizing tone.

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

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.

>>> 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.
>>
>> I have gone beyond this, by inspection at the spreadsheet level that
>> the symlink ownership by the package 'makes sense'. You've pointed out
>> below that a toolchain could be responsible. Spreadsheet-level
>> inspection is a reasonable filter for catching these.
>>
>> Yes, it is possible for there to be cases in THE 86 PACKAGES that the
>> expertise of the maintainer will be involved in targeting the
>> ultimately right package. I do not believe that is inappropriate.
>>
>> Perhaps we need a mechanism for arbitrating this? Or a plan that
>> recognizes that I am not up for doing this for 86 PACKAGES. Otherwise
>> we could be looking at another brick wall.
>>
>> As a separate issue, this raises additional questions on how you wish
>> to list the maintainers section. That remains open.
>>
>>>
>>> Looking at xmanpages-ja from your list, that is also serious:
>>>
>>>  /usr/share/man/ja/man3/XLockDisplay.3.gz ->  XInitThreads.3x
>>>
>>> the link target is missing the .gz extension (and policy says somewhere
>>> that links to compressed files must have the same extension)
>>>
>>
>> Ok, will research. That would be the second category, in my book.
>>
>>> rebuilding in sid fixes this issue
>>
>> Guaranteed? Only if dh_installman is doing the work, right? Is this
>> because dh_installman changed behavior recently? Otherwise, more
>> explanation please.
>
> I tried it. rebuild-in-sid is a handy local script (all it does is
> apt-get source && pbuilder build with appropriate options).
>

Ok, its all yours. I'll retest for the spreadsheet after the next release.

>>> there are lots of broken links to jquery.js and friends - please
>>> investigate, this may be a toolchain bug, too (or a "missed" transition)
>>> (this should be analyzed in stable, too)
>>
>> I did look at this, for at least a sampling of cases. jquery was a
>> recommended package.
>
> 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.

>>> * a bug should be filed for xmanpages-ja, no d-d discussion needed,
>>> intent-to-NMU
>>
>> Will prepare bug(s). I don't intend to NMU (can't actually - you want
>> this?). xmanpages-ja will still come up again at the 'normal'
>> conversation.
>
> I'll NMU if needed, not sure if the maintainer is still active.
>
>>> * we should have a specific d-d discussion about filing broken .so
>>> symlinks in -dev packages as serious - how many would that be?
>>
>> Glad you asked :-). 82 BINARY PACKAGES, 66 source at last count.
>>
>> Sorry, you said -dev packages. I can't right now. Try grepping the csv
>> on serious and -dev.
>
> there should not be a big difference
>
>>> Rationale: a -dev pkg that cannot be used to link against its library is
>>> useless
>>
>> or more simply a violation of "Packages containing shared libraries
>> must be constructed with a little care to make sure that the shared
>> library is always available". A violation is a violation. Serious is
>> serious. More nuance is not required.
>
> -dev packages (Section: libdevel) don't contain shared libraries. The
> provide only the .so link needed at link time to find the real shared
> library ...
>

For purposes of the Policy, I don't see a difference, in the case of
broken symlinks. It's a file that purports to be a shared library that
can't be used as such, meaning that it is a 'serious' issue
(notwithstanding the PACKAGE dir situation). I don't see how more
analysis along these lines will change that.

>>> For the bug template:
>>> Subject: $PKG: Broken .so symlink due to missing Depends: $DEP1,$DEP2,..
>>>
>>
>> Per previous objection, I see this as
>>
>> Subject: $PKG: Broken .so symlink
>
> getting the package providing the wanted file is easy :-)
>

Not sold on the utility.



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?