Re: Autocompilation and source dependencies
Santiago Vila <sanvila@unex.es> writes:
> On 29 Oct 1998, Brederlow wrote:
>
> > We (Falk hueffner and me) have started to do some real autocompilation
> > programm/script. Source dependencies should be determined by the prog
> > itself and then stuffed somewhere into the package.
> >
> > [...]
>
> Great!
>
> I would just like to comment about this:
>
> > - The build will usually fail, because the basic tools are not
> > installed. Its probably a good idea to install a set of tools by
> > default and have a look at the dependencie output later to see if they
> > are used at all. Once a package was build correctly, only the needed
> > packages will be installed.
>
> I think that this leads to the idea of a "base system" or
> "source-essential-packages" for building.
I'm planing to experiment with just such a thing. I have two m68k, one
i386 and on alpha System running Debian. I don't want to waste 3 GB of
diskspace for various mirrors, but instead want to have one source
mirror and the essential tools to rebuild everything. I would like a
two CD set containing all of surce and all needed bins for ALL
architectures. At installation time the System would compile itself
for the right architecture.
> We talked about this some time ago in debian-policy. I would advocate for
> making the base system as *little* as possible, so that we do not "lose"
> any valuable information.
>
> For example, if a binary package depends on libc6, clearly the source
> package needs (almost always) a C compiler, libc6-dev, binutils, and make.
I think every Package will depend on libc6, since dpkg-buildpackage is
a perl script (isn't it?) and perl uses libc. Without libc, no
package could be compiled. Sometimes its suprising to see what is
needed to build a Debian package.
Our script (or better libtricks) will report any and all files used,
so nothing can be missed (Thats also the main reason for the speed
penalty). If any Package, that is mentioned in the dependencies, is
missing, the compilation will not be able to use it and most likely
fail, otherwise it wouldn't have been added to the dependencies. A
Package that looks for tcl for example, might compile without, but the
script will still report a dependency on tcl and next time the package
gets compiled it will find tcl.
I don't want to presume anything at the moment and the dependencies
won't be filterted at the moment. I first want to have a realy
complete list of dependencies and then one can look further. I think
the few lines of dependencies that could be erased are not worth the
effort in programming and the decisions what should be erased might be
wrong. What does it matter to save 10-100 (thats probably way to high)
package names (40 chars each in average?), thus saving 4 K
uncompressed data, on a 35 MB X Source?
Even if its 10K compressed data for each package, thats still only 1-2
MB for the complete Debian mirror.
> We will not lose many information if we drop that from the source-depends
> field (the day we have a source-depends field).
The dependencies could be cleaned after autocompilation and sanity
checks, but at the moment, why not just leave them in and see how much
extra data it is anyway.
> I consider useful information however, that a package needs bison, flex,
> libstdc++2.x, automake, or autoconf for building, even if many of those
> tools have Priority: standard or higher, and therefore I think these
> tools should not be part of the "source-base" set of packages.
I would consider those absolutely essential for a compiling system and
would flag them "base" (for a source distribution). On a closer look,
I'm sure several or all could be compiled one after another (in the
right order).
I also want to see what depends on what in base. Filtering
dependencies on base out would ruin those data.
Consider somebody starting a new port of Debian. He would look at the
source dependency tree and see that he needs to crosscompile gcc,
make, sh and get a kernel running. Everything else he could then
compile on the new system.
May the Source be with you.
Mrvn
Reply to: