Re: [gentoo-dev] Stage1 and dependencies

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 26 June 2004 17:06, Robin H. Johnson wrote:
> On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote:
> > Issue #1: Ignoring dependencies
> > The "cleaning" of the vardb to trick portage is IMO a bad thing. There is
> > obviously enough in a stage 1 to be able to build up all of system, but
> > according to the data portage it is impossible. This then requires a hack
> > as indicated above to attempt the merge anyway. However, this hack
> > affects users of installed systems as well as portage will go ahead and
> > attempt a compilation that is guaranteed to fail.
>
> What's your solution for this?

Well, I don't actually understand why the var db needs to be cleaned. I can't 
see why a combination of --nodeps and --onlydeps on package x and y can't 
solve whatever the problem is, though...

> > Issue #2: Lack of dependency information
> > Looking at the above, linux-headers doesn't need bzip2 to unpack,
> > ncompress and db don't need glibc to build and almost nothing needs gcc
> > to compile. It gets much worse when doing emerge -ep world. If it's too
> > much of a PITA to fix this for all packages, portage could ensure that
> > all of system is installed before anything else, but this needs to be
> > 100% explicit for the base system. I don't believe it's as difficult as
> > it sounds - a few eclasses such as bz2files, csource, cppsource, etc
> > should be sufficient. However, without accurate information, parallel
> > emerges are just a daydream.
>
> I've got no objections to putting the correct information into the tree,
> but portage needs to be able to handle circular dependancies much better
> first. One other glaring problem in your listing is sys-devel/make. One
> other thing that will bite at some points is the things that some
> upstream developers put into their configure scripts, that are decidedly
> not always present on a system (perl and rpm to name the worst offenders
> I've seen). If you can tell me I won't run into any problems by adding
> in the deps for virtual/libc virtual/cc sys-devel/make etc into my
> packages, I'll go around and correct them now.

I don't think that the change would bring about any more bad dependency 
ordering than already exists, but I can't be sure. Perhaps, the solution is 
to fix the dependency resolver then fix the packages and then enable parallel 
emerges. That sound acceptable?

> virtual/cc is something I think should exist, as some people want to use
> dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc.
>
> Also, where does the adding of dependancies stop? Eg I have something
> that uses kernel-headers and glibc, so do I just specify glibc and
> ignore kernel-headers as that's needed by glibc?

That's a design question that's open to debate. Portage can do it either way, 
but I would suggest that the package depend on both kernel-headers and glibc 
for robustness in the tree. Unlikely in this case, but it ensures that a 
change to glibc's dependencies don't break the packages that depend on it.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQN1Bh1oikN4/5jfsAQIn1AP+JpYCphzGsFLJlm6hnntLfGaJ+KWjjb61
UNR4sw7q/qRq4GfNliBfNetb16K6jjBRseZUrt9p5ofdjgu6nCxEyfl5F+0QyPSH
sAZq0eqFcobARU+TUPGGBeJG82ve46BJDCTPF4ieK3dFm4/0sfRYHz+DAYQnNFG6
eq507/u1bRM=
=3rkH
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list