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

Re: Source dependencies


On 24 Feb 1997, Michael Alan Dorman wrote:

> Ian Jackson <ian@chiark.greenend.org.uk> writes:
> > It is becoming clear from our porting bootstrapping efforts and
> > various other things that source dependencies are probably required.
> I think it's clear that a lot of people are under the _impression_
> source dependencies are probably required, and I think your proposal
> (with Guy's modification) is probably a sensible way to implement
> that.

I second that.

> But in working on the Alpha port, and thinking about the "single
> source tree" idea, I am unconvinced that source dependencies are
> really going to solve anything.  Please consider:
> In porting to the Alpha, I have only found a couple of packages where
> it would have made much of a difference---and even then I only wasted
> a few minutes compiling the tool I needed before restarting on the one
> that cause the problem.
> Mind you, I've not finished base and the various compiling-type tools
> yet, and it may be a different thing once I'm working on a wider
> spectrum of packages, but there are so many other issues with porting
> I wonder whether source dependencies are going to really be of much
> value.

Dependencies aren't that much use with dpkg - you need to use dselect for
them to become more apparent. I think the same would probably apply if we
wrote a "dselect" tool (or extension) for getting and unpacking source

> Even just porting to glibc, which is another thing you always hear
> mentioned, you have to go back and stick #include <errno.h> in an
> awful lot of code, and #define __GNU_SOURCE all over the place, so
> source dependencies will be of only occasional use.

Isn't __GNU_SOURCE _supposed_ to be predefined in the compiler specs file
when you're compiling with glibc?

> In fact, I also have my doubts about the single tree rebuild concept,
> because the only reason I've seen for supporting it is "to ensure a
> system that's been compiled with a consistent set of tools, etc.", but
> we're not actually going to be able to provide that unless:
>  1) We mangle make files for every package to insure that during
>     linking they first look at ../libc for tools to link to, or
>  2) Somehow contruct a chroot'd environment as we go along, and link
>     against this.

Hmmm... GNU libtool manages this _really_ nicely. Perhaps something along
the lines of this would be nice...

> Otherwise, if the compiling person's got libc-5.2.18 on her machine
> and recompiles everything, even if glibc-2.0.1 is in the source tree,
> it's not going to be what everything is linked against, so the whole
> idea of "turn it on and walk away" is not applicable---and if you
> can't do that, what's the value-add?
> Or am I missing something?
> Mike.

- -- 
Tom Lees <tom@lpsg.demon.co.uk>			http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E  B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)

Version: 2.6.3i
Charset: noconv


Reply to: