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

Re: source dependencies



On %M %N, Juergen Menden wrote
> 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?

if i remeber correctly, emacs and perl have gnu autoconf configure
scripts. these scripts only use parts we know (shell, gcc, cpp and other
stuff that is either base or essential or listed above or required by
one of these parts). 

> please look there, and get a feeling of the problems we will
> have to face.

why look at all scrips ? run them. if something is missing, install it
and add an entry to source-depends:

> 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.

the list is ment to not include base stuff, but be complete with the
rest. the main focus is requiring source code or development part of
libraries, and tools like flex, bison and debmake. these are easy to
find.

> how about calling them 
>    helpful:
> instead of 
>    depends:

that doesn't help. Source-Depends is the better name.

> > 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.

it is easy to find :
a) development part of libraries (look for -lxxx lines and #include
	statements, or at the binary)
b) source code requirement (it's easy to find out, that you cannot
	compile tk without tcl source code, isn't it ?)
c) use of flex, bison, debmake, lex, yacc
d) use of very special programm you have to install to compile xxx

these 4 targets will help a lot, i don't think there are many programs
that we miss with this list. (do you have some examples what i forgot
?)

> 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.

it is meant to need special programs. we will not start to list 
cat,ls,make,gcc,cpp,cp,install,mv,ln,perl,dpkg,tar,gzip,...
that doesn't help. 

our goal is to give a checklist what you need to compile, before you
unpack the source. we can assume that someone has a debian system, so he
has the base packages, the essential packages, the list of packages
given, and everything required by these packages.

> 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.

no. isdnutils scans for ncurses, tcl, x11 and kernel source. maybe you
can compile the program without these packages, and you have a isdnutils
package, but that is not the package i maintain. it will not have
vbox,imon,imontty,xisdnmon,xisdnload and most other stuff, so it will be
useless for most persons. 

we don't want to compile something. we want to reproduce the debian
package from the source + patch + dsc, and we want the same result.

> > 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?
everything. all >900 packages, 50% worked fine, the other 50% not.
 - missing dependencies for source code (e.g. kernel-headers, tcl source
   ...)
 - missing development stuff not installed on the machine (e.g. publib-dev)
 - problems with glibc2 (e.g. errno.h)
 - bad packages (e.g. programs using su or sudo, or installing files
   into the normal filesytem instead of the debian/tmp root.

source-depends will help :
 - the script can unpack needes source code in a well defined place.
 - the script will not try to compile packages without installed
   development libraries.

we should also copy the architecture: field in the dsc file,
so the script can skip arch independent packages (you don't need to
compile them again and again on all plattforms).

> i know the problem from my porting days. its frustrating. :-)
> but you do not really need that overkill.

why overkill ? i don't think that it's much work. most mainatiners konw,
if their packages need bison, flex or debmake, and they can look at the
binaries or the Makefiles to determine which libraries are needed.

> just define some order which works, whether there really exists a
> dependency or not. 

order ? when we start compiling anythin that is in Incoming, the
packages are given, not much order to choose. and that doesn't help with
packages like tcl/tk, that need another packages source. at least that
is easy to do, and not much work. adding a few hints like "flex, bison,
debmake" and "publib-dev" will not hurt.

and if you don't want these dependencies : you don't need to look at
them. dpkg-source can give you a nice hint, that you will not be able to
compile the package. if you still want to try, nobody will stop you.

if you don't like the term source dependencies, you can think of it as a
small list for compile scripts and information to do some statistiks.

andreas


--
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: