On 04 Sep 2006, at 12:32, Martin Costabel wrote:
> Benjamin Reed wrote:
>> I did some investigation of the node exists errors, and I think
>> they are
>> completely bogus (at least, while I agree we shouldn't have gotten to
>> that point in the code path in the first place, I believe it is
>> entirely
>> legal to ignore the error).
>>
>> I've done some Data::Dumper debugging, and basically I think what's
>> happening is as it's going through and making the list of packages to
>> investigate for dependencies, it's somehow hitting a package twice.
>> When it's time to add it to the hash of things to check, it says "I
>> already have this in the hash" and it bombs.
>>
>> The stuff that goes into the hash is generated like this:
>>
>> @{$deps->{$dname}}[ PKGNAME, PKGOBJ, PKGVER, OP, FLAG ] = (
>> $dname, Fink::Package->package_by_name($dname),
>> $dp, $OP_INSTALL, 2
>> );
>>
>> ...by the time it comes up, there is no way this information won't
>> always be identical to what's in the hash already.
>
> Hmm, if it were identical, it wouldn't get there at all. There is an
> earlier test
>
> if (exists $deps{$dname} and $deps{$dname}->[PKGVER] == $dp) {
> ...
> next DEPLOOP;
> }
>
> So if it's really the same version, it quits before coming to the
> error.
> The "node exists" error comes from
>
> if ($dp->is_installed()) {
> $dname = $dp->get_name();
> if (exists $deps{$dname}) {
> die "Internal error: node for $dname already exists\n";
> }
>
> So it kicks in only if there is a different version already in the dep
> list, and the version on the dep list that is currently examined
> corresponds to the installed version. As I see it, if you simply
> ignore
> this, you may then hand a conflict to dpkg that it cannot handle.
>
> IIRC, years ago we used to have many more of these "node exists"
> errors,
> and the code was fixed to remove the bogus ones. Now it is extremely
> rare and chances are that if it happens, there is really something
> wrong
> with the dependencies.
>
>> "Fink::Package->package_by_name($dname)" interrogates the index,
>> which
>> is already up-to-date and unchanging by the time this loop is
>> encountered, so at worst, we will be checking postgresql81-dev if it
>> matches the dependencies multiple times.
>>
>> I think the "node exists" die should instead be replaced with "next".
>>
>> Empirical testing with a reproducible error on my dev system implies
>> this is safe, as well. :)
>
> Is this reproducible by others as well?
It has nothing to do with Provides ? (maybe because they are
unversioned ?)
A vague memory is that, if I played a bit too much with Provides, I
easily created such examples...
JF
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
