> Douglas Kline <[EMAIL PROTECTED]> said:
> >
> > Now I'm getting a different error: The variable basepath is being defined
to
> > its own name as a value in Engine.pm. When Engine.pm starts, the variable
is
> > undefined. In the initialize sub-routine in Engine.pm it's defined in the
> > command
> >
> > $self->{basepath} = $basepath = $config->param("basepath")
> >
> > to its own name which, of course, leads to an error.
> >
> > Earlier tests before I ran into this problem showed that fink was able to
> > locate the pathnames correctly in at least some cases. Any ideas as to wha
t's
> > going wrong here? Should that sub-routine in Engine.pm be getting the corr
ect
> > value from somewhere or should it be set elsewhere?
>
> I don't understand that analysis. The $config object, which is a
> Config not an Engine, was established in Engine::new_with_config().
> What's the exact error you're getting? Insert some print statements
> there to see what the values are.
The error I get is:
Failed: Can't cd to basepath/fink: No such file or directory
I had already tried the print statements. Near the beginning of Engine.pm,
just before the line
END { } # module clean-up code here (global destructor)
The output of
&print_breaking("ENGINE: basepath is $basepath.");
is:
basepath is .
So at that point the variable is undefined or defined to null. In fact it's
the former. Just before that output but after the output of a place-marking
diagnostic line I inserted too, I get the message:
Use of uninitialized value in concatenation (.) or string at
/a/kodos/DataCenter/FINK/src/fink.build/fink-0.24.10-21/t/basepath/lib/perl5/Fi
nk/Engine.pm line 125.
Inside the initialize sub-routine, just before the end of the sub-routine, the
output of the same diagnostic command is:
basepath is basepath.
So now the variable has its own name as a value. Inside the process
sub-routine, just before the if-statement that runs restart_as_root which I've
commented out, the output of the diagnostic command is the same as the previous
case. Then I get the error message from the cd command.
I'll look into the new_with_config sub-routine. However it seems that the
commands I've cited show that the variable is being defined in Engine.pm.
> >> If dselect is the stumbling block, just hack the apt package to avoid
> >> building it.
> >
> > So far as I can tell, dselect isn't the stumbling block since it's not
> > mentioned in the error messages and the routines to which I've traced error
s
> > aren't building dselect. I mentioned it because the documentation says tha
t
> > it's one of the tools that this installation creates and it wasn't created.
>
> I've heard that the bootstrap script sometimes doesn't abort if there
> are certain package-building errors. That means one gets incomplete
> packages, and perhaps some chunks of the build process aren't being
> run. It would be in the "dpkg" package if it were created.
That could explain why fink wasn't installed in a bin directory but rather is
src/fink.build/fink-0.24.10-21/fink and wasn't set with execute permission and
might explain the above malfunction if something else is missing and some step
didn't happen.
In which directory would dselect be found? There are some dpkg directories and
files but there is no file named "dselect" in the whole tree that the
installation created.
Thanks for your help.
Douglas
========
Douglas Kline
[EMAIL PROTECTED]
_______________________________________________
Fink-beginners mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-beginners
