Re: Source dependencies
-----BEGIN PGP SIGNED MESSAGE-----
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
distributions.
> 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)
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBMxdYov152HGH1NBlAQEJugQAkVfrugfg7Psr2X5cHNq1ViodZNR6DaIm
yhVvwNOikPFyEMckjuIJepYGtw2w8Vf6o7hHNg6Hp5r7F8Hd+O58qAJaOhqpsF2D
ktt05Y9jSGFp3AEqXuEV30ZLxR1sxQo5nKTZGr4R+CFUCXeAV5QCwVC+vXA1VLdv
OrCcWrZUBN4=
=a1aU
-----END PGP SIGNATURE-----
Reply to: