Re: source dependencies
On %M %N, Juergen Menden wrote
> please, everyone should remember that this can _always_and_ever_
> _only_ be an incomplete list of what tools might get used during
> 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)).
> if there are: has anyone ever tried to find all programs
> Configure-scripts (like the one used in the perl package) uses? Or the
> poor X11 maintainer who would have to check thousands of lines of
> recursive makefiles to find all the tools used, and even which tools
> are used by programs build at earlier stages during compilation. apart
> from gcc, which depends on gcc :-)
hey. we define a base set of tools (current list : all base and
essential tools and these tools (and evrything they depend/require) :
binutils dpkg-dev file gcc libc-dev make patch perl
> this is an _impossible_ task. i don't mean its uncomfortable,
> which it is, i mean this is really impossible (at least within
> polynomial time, said the theoretican).
ok. but better have a nearly complete list, than no list.
at least source dependencies for other programs source are easy to find
out, and it's a first step. add the development part of libraries
(ncurses, xlib, xpm, ...) and tools like flex and bison, and you have a
> ok, so far the bad news. now, since aparently some people
> seem to suffer from this deficiency, a compromise: would
> those people, who have such problems, would be satisfied with
> a few lines in debian/readme where only those of the "unusual"
> tools are listed, which the maintainer found interesting, but
in the debian/readme ? the idea of the source dependency is to make
sure, that all tools requires for compiling are present, or wait
till they are installed. with a list in debian/readme we had to extract
the source, and a script cannot read that. not a good idea.
> 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.
> BTW: who are the people which have such a problem? i've
> worked for some time in the very early stages of the m68k port
> and i never had any real problem with this.
i ran my auto compiler : 50% compiled. the other 50% did not compile.
debian should have a good quality, 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.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .