[Piuparts-devel] bug doc

Andreas Beckmann anbe at debian.org
Sun Jun 30 11:17:51 UTC 2013


On 2013-06-29 15:31, Dave Steele wrote:
> Let's see if this fits as plain text.
> 
> Here's a courtesy copy of the latest bug filing announcement. I'll
> send it out shortly.
> 
> ----------------------------------
> 
> 
> Subject: Mass bug filing for shared library broken symlinks detected by piuparts
> 
> 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.
> 
> This message covers the bug filings at the 'serious' severity due to a
> Policy violation involving shared libraries. Section 8 states
> "Packages containing shared libraries must be constructed with a
> little care to make sure that the shared library is always available".

> Discussion about bug filings at other severities may be handled in
> separate threads.

That sentence is confusing. I put a suggested replacement two prragraphs
below, so that there is a bit more content about "there are several
other classes of broken links".

> The package list was generated by running an instance of
> piuparts-slave/piuparts-master against sid, with the option
> "--fail-on-broken-symlinks" enabled. The resulting list was
> hand-massaged to eliminate a few packages which failed through the
> fault of a dependency. These 'serious' bug candidates were identified
> by testing the symlinks and targets against the regular expression
> "/usr/lib/.*lib.*so".

^(/usr)?/lib.*/lib.*.so.*$

> There are 82 binary packages in this list, represented by 66 source
> packages and 53 maintainers. This is about a quarter of all of the
> packages reporting broken symlinks. A total of 279 broken symlinks are
> being flagged as 'serious' due to shared library issues.

"Mass bug filings for different classes of broken symlinks will be
discussed separately."

> To see a piuparts log showing the broken symlinks, find the package
> under http://piuparts.debian.org/sid/broken_symlinks_issue.html and
> search for "WARN: Broken symlinks". That web page also lists reverse
> dependencies of packages with the issue.

... the number of reverse dependencies ...

> The initial bug reports will be based on this template:
> 
>     Subject: Broken library symlink detected in <binarypackage>
> 
>     Package: <binarypackage>
>     Version: <version>
>     Severity: serious
>     User: debian-qa at lists.debian.org
>     Usertags: piuparts, broken-symlinks, broken-symlink-shared-library
> 
>     Hi,
> 
>     During a test with piuparts, I noticed your package is
>     responsible for the presence of broken symlinks. Such failures
>     may indicate a significant problem with the package.
> 
>     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.

For broken .so.* symlinks, is there really a use case for using triggers
instead of Depends?
We should not hint maintainers into using a wrong solution for this
problem ...

>     This is being filed as Serious because it represents a violation
>     of Policy. Section 8 states "Packages containing shared
>     libraries must be constructed with a little care to make sure
>     that the shared library is always available".
> 
>     A link to the log containing the indicated broken symlinks can
>     be found on piuparts.debian.org[3]. Search for "Warn: Broken
>     Symlinks" to see the failure point. A log showing the broken
>     symlink as an error is appended.

Turn this around, more relevant information should come first:

      A log showing the broken symlink as an error is appended.
      Search for "Warn: Broken Symlinks" to see the failure point.
      A list of all packages with broken symlinks together with the
      logfiles and links to the corresponding bugs (if any) can
      be found on piuparts.debian.org[3].

>     The specific symlinks are as follows:
> 
>     <symlinks for binarypackage>

<link> -> <target>, please

>     Note that there may be other broken symlinks. See the log for a
>     full list.
> 
>     [1] - file:///usr/share/doc/dpkg-dev/triggers.txt.gz
>     [2] - http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/
>     [3] - http://piuparts.debian.org/sid/broken_symlinks_issue.html
> 
> 
> Regards
> 
> Dave Steele
> 
>     ----
> 
>     <log for binarypackage>

gzip compressed?

> Following is a list of affected packages, by maintainer. 

format is "<binary-package : source-package>" ??? Should be described.

> The symlinks
> involving shared libraries are also listed. Note that there may be
> other broken symlinks detected by piuparts with these packages.
> 
> A. Maitland Bottoms <bottoms at debian.org>
>     libdime-dev : dime
>         /usr/lib/libdime.so

Can you make that <link> -> <target> ???

> Andrew Ross <andrewross at users.sourceforge.net>
>     libplplot-dev : plplot (5.9.9-5)

and drop the version number here ...
(The Source: field in a binary package contains a version if source and
binary packages have different versions - could be binNMU or e.g.
manually added epoch for a single package.)


Andreas



More information about the Piuparts-devel mailing list