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

[Andreas Beckmann]

On 2013-06-02 13:59, Dave Steele wrote:
> On Sat, Jun 1, 2013 at 7:32 PM, Andreas Beckmann <anbe at debian.org> wrote:
>> Due to different --warn-on-leftovers-after-purge settings these two are
>> not easily comparable.
> 
> Yet they are not that far off.
> 
> That current list of ... now 18000 packages tells me right at the top
> that perl_5.14.2-21 is responsible for broken symlink issues in 7000
> logs. That's not useless. That's gold.

yes, dependency counts add some value to this list (but I never looked
at them becuase they were utterly useless before this)



So let's dig into the lists (only the .csv you sent is usable), let me
start with the serious ones and pick a random one ...

The d-d mail should clearly detail the different categories we sort the
broken links into and a list of common causes that could have lead to
this link ...

(from analyzing libuim-dev, libsquizz-dev)

  Tag: broken-symlink-libdevel-so
  Severity: serious
  Broken link: /usr/lib/libFOOBAR.so -> libFOOBAR.so.42
  Problem: libFOOBAR-dev package with libFOOBAR.so link misses
           Depends:libFOOBAR42
  Reason: forgotten dependency
  Reason: multiple libraries built from src:FOO, maybe split into
          separate packages after some time, but the (single) -dev
          package was not adjusted to depend on all library packages

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.

That seems to cover most of the broken links in /usr/lib, and I fully
agree to file them as serious.
I would be a bit more careful with broken links in "package specific"
directories like /usr/lib/PACKAGE/, but if a missing dependency is
obvious, that should be serious as well.


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)

rebuilding in sid fixes this issue
Are there more packages of this type?
There I would suggest to do "sourceful-rebuild-NMUs" (similarly what was
done to switch large gnome/kde packages to xz to get more onto CD1)


lots of kde packages have a broken symlink to ../../common
I would expect that is an error in the toolchain used, please
investigate and file a bug against the toolchain (check experimental
first, might be fixed there)


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)


libpythonX.Y-dbg has many broken links in /usr/include, please
investigate, probably a missing Depends on a corresponding -dev package?
maybe a reason this is missing?


anything involving /etc/alternatives is a false positive and a separate
bug should be filed already


src:mpich causes several broken links in /usr/bin

=======

>From looking at the list of broken links and digging into some of the
packages I conclude:

* serious bugs should be files for broken links in /usr/bin, no d-d
discussion needed (4 source packages)
* a bug should be filed for xmanpages-ja, no d-d discussion needed,
intent-to-NMU

* we should have a specific d-d discussion about filing broken .so
symlinks in -dev packages as serious - how many would that be?
Rationale: a -dev pkg that cannot be used to link against its library is
useless
For the bug template:
Subject: $PKG: Broken .so symlink due to missing Depends: $DEP1,$DEP2,..

* we should not have a general broken-symlink discussion on d-d right now

* the other broken symlinks need further investigation
  (if they are toolchain bugs, filing against the affected packages
   would be very wrong)

If we want to escalate broken symlinks in piuparts, we should limit this
to broken /usr/lib{,/<triplet>}/*.so for now.
But maybe the adequate check for broken symlinks is more adequate for
this is this is easily limited to the broken package, while the piuparts
check is "global" (which is a good thing to find broken non-shipped but
buggy-maintscript-created stuff).
And the adequate output is getting parsed already :-)


Andreas