Re: source dependencies
On Sun, 27 Jul 1997, Andreas Jellinghaus wrote:
>
> > is there really somewhere around who is truely sure what tools
> > autoconf-created configure scripts call?
>
> of course. configure scripts use only a well known set of tools
> (sh, gcc, cpp, sed, (i could look if it takes any others)).
please do so. aparently you havn't looked at many configuration
scripts by now. for a good start i recomend the tex configure
scripts, please look at the web2c part (together with the
kpathsea script which is needed as you will see)
the next stop might be some scripts in the Configure style
(like in perl, some problems are already addressed there,
but were _very_ hard to find).
take a look at emacs configure, is it now better then it was
in 19.11?
please look there, and get a feeling of the problems we will
have to face.
> ok. but better have a nearly complete list, than no list.
ok with me. just try to make it clear that this list is not
ment to be complete, it's just a helpful hint for bootstraping
a debian system from scratch.
how about calling them
helpful:
instead of
depends:
> the idea of the source dependency is to make
> sure, that all tools requires for compiling are present,
which in turn would make bootstraping rather a . . . .
one should be able to compile a debian package on a non-debian
system.
> > sounds nice. the only problem is: how do you decide which
> > packages are needed for compilation?
>
> we dropped all base tools, all essential programs, dropped other tools
> (list : binutils dpkg-dev file gcc libc-dev make patch perl) you need
> to compile, and now the list shouldn't be very long.
good, but that was not my question. the question was: can you
give a general procedure to decide which packages some source
depends on? if you try to be complete you will have to have the
complete list to remove all "asumed-to-be-present" things.
again my credo: make it sure that such a list might be helpfull
for some tasks, but it is not, and is not ment to be, complete.
and don't require compilation depend on such a list. how would
you deal with packages (like most ones nowadays) which scan the
system and simply configure differently if some packages are there
or are missing. such things seem to be useful.
> > BTW: who are the people which have such a problem?
>
> i ran my auto compiler : 50% compiled. the other 50% did not compile.
do i understand right: you try to recompile a large amount of debian
from a script?
i know the problem from my porting days. its frustrating. :-)
but you do not really need that overkill.
here you need some hand-work in trying to establish
some order. but this task seems to be much easier then trying to
find a complete list of source-dependencies.
just define some order which works, whether there really exists a
dependency or not.
again: you do not need to be exact, you only need some helpful
hints to save you some work.
> debian should have a good quality,
which is just my concern. we should try to be helpful, and
for that we can give some hints. if we create some strict
dependencies, which will not work, quality will suffer.
> and this includes, that everyone
> should be able to compile our packages. and to make this job easier, we
> should give a list of packges she needs to compile a given package xyz.
[most of you know the following, nevertheless it's a nice story]
in the 50s one had to give an hint about the running time of a
program. when this time expired, the proc is dumped to prevent
a programing failur resulting in an endless loop to block the
whole machine.
much time was wasted because of a just too small hint.
engineers at ibm thought, it might be helpful to write some small
preprocessor which decides if there is an endless loop in the
program or not.
this was right, it would be helpful. unfortunately such a question
is not decidable. with no programm ever.
ibm paid only a few millions of US$ until the project was stopped.
-----
not all what might be useful to have, can be done. complete
dependencies might be helpful to have, but are impossible to
create.
jjm
ps: for the more theoretical reader:
i'm not completely sure if it is decidable or not. the alg.
must have to decide which parts of the configuration and build
stages are used and which are not. this is because some tools
might only used in some specific configuration and not in others.
but then, turings halteproblem should be reducable. any other
theoretical computer scientist around with some spare time? :-)
pps: i am completely sure that it is _much_ to hard to handle,
even if it would, to my supprise, be decidable.
--
Juergen Menden
at work: menden@informatik.tu-muenchen.de tel: +49 (89) 289 - 22387
private: menden@morgana.camelot.de tel: +49 (89) 89 712 743
Support the anti-Spam amendment. Join at http://www.cauce.org/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: