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

[Dave Steele]

On Sun, Jun 2, 2013 at 11:08 AM, Holger Levsen <holger at layer-acht.org> wrote:
> Hi,
>
> On Sonntag, 2. Juni 2013, Dave Steele wrote:
>> >> >> ... 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.
>> >> >
>> >> > you mean if the broken symlink is provided by a dependend package? I
>> >> > dont think thats a bug at all then.
>> >>
>> >> No. The target is provided by a reverse dependency, which is the
>> >> normal installation case.
>> >
>> > if the missing symlink is "fixed" by a dependent package I don't think
>> > there is a bug anywhere. thats what depends are for.
>>
>> Not "dependent". It's "reverse dependent". When testing a package, how
>> do you guarantee that a reverse dependent package is going to be
>> installed? This leads to the strategy of using triggers to add the
>> symlinks only when the rdep arrives.
>
> I'm not I can follow you, can you give an example please?
>

It is a similar case to 'Recommends'. Can I link to a Recommends file,
without consideration of if it is there or not?

Consider a package foo-common, which links to a file 'wordlist'.
foo-common doesn't actually provide that file, so a piuparts test will
validly show a broken symlink. The file is provided by any one of a
list of other packages, foo-en, foo-es, etc. The language-specific
packages all properly depend on foo-common. A piuparts test of any of
the foo-<language> shows broken symlinks at the piuparts-depends-dummy
phase (this should probably never be considered a failure), but not
necessarily after that.

In the real world nobody installs foo-common - they install foo, which
eventually calls it in. So, do we tell foo-common to create the link
based on a trigger, or do we consider this not a failure? Does it
matter what level of a guarantee we can expect an rdep to take care of
unbreaking the link? How do you determine the quality of the
guarantee?

This is at least a component of the situation for dictionaries-common,
though there are nuances that I don't recall at the moment. Its rdeps
can fail at the package install/uninstall step as well.

dictionaries-common has symlink failures represented in 1200 packages,
including mine. It is the reason I am working this issue now.