[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#715080: Broken library symlink detected in libgcj12-dev



Control: tag -1 - moreinfo

On Sat, Jul 6, 2013 at 9:32 AM, Matthias Klose <doko@debian.org> wrote:
> Control: severity -1 normal
> Control: tag -1 + moreinfo
>
> On 07/06/13 07:01, David Steele wrote:
>> Package: libgcj12-dev
>> Version: 4.6.4-2
...
>> The log contains the following broken symlinks:
>>
...
>>   /usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre/lib/amd64/libjawt.so
>>     -> ../../../../../x86_64-linux-gnu/gcj-4.8-14/libjawt.so
...
>
> please fix your script before posting incorrect information. why should a link
> in gcj-4.8 files as asn issue for gcj-4.6?
>

The precise answer is because after installing and uninstalling
libgcj12-dev the broken symlink is detected, while this does not occur
for any of its calculated dependencies.

The symlink above is actually introduced by gcj-4.6-jre-headless,
which has failed for the same link path.

The mechanism appears to be dependency ambiguity introduced by
circular dependencies in gcj-4.6. Piuparts broke the loop in the
'wrong' place for this particular issue, causing libgcj12-dev to be
tested before gcj-4.6-jre-headless has a chance to block it with a
failure.

Circular dependencies are an intractable problem for piuparts. And,
the bottom line is that libgcj12-dev does fail a piuparts
install/uninstall test. I'd suggest that the resolution here is to
eliminate the circular dependencies, or tolerate the ambiguity (though
I understand the tractability issues there as well).

Having said that, I could have checked for duplicate symlink reports
across the bug reports for the mass filings to detect some cases for
this kind of issue. I'll remember that. Though, this would have not
helped in this case, because gcj-4.6-jre-headless was eliminated from
the candidate pool due to an earlier report (#705984).

I agree that this bug report, as an instance of broken share library
symlinks, is not valid. Broken symlink issues remain with the package
though, and your updated severity seems appropriate. I'd suggest
leaving it open.

--
"Le mieux est l'ennemi du bien" - Voltaire


Reply to: