From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30853 invoked from network); 26 Jun 2004 09:30:10 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 26 Jun 2004 09:30:10 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Be9Vh-0007Ls-0F for arch-gentoo-dev@lists.gentoo.org; Sat, 26 Jun 2004 09:30:09 +0000 Received: (qmail 32498 invoked by uid 89); 26 Jun 2004 09:30:08 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 21126 invoked from network); 26 Jun 2004 09:30:08 +0000 From: Jason Stubbs To: Gentoo Developers Date: Sat, 26 Jun 2004 18:27:30 +0900 User-Agent: KMail/1.6.52 References: <200406261506.56943.jstubbs@gentoo.org> <20040626080622.GA7174@curie-int.orbis-terrarum.net> In-Reply-To: <20040626080622.GA7174@curie-int.orbis-terrarum.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Message-Id: <200406261827.36325.jstubbs@gentoo.org> Subject: Re: [gentoo-dev] Stage1 and dependencies X-Archives-Salt: c7b04234-2b65-4d59-876a-b6ef3fed0d57 X-Archives-Hash: 6f4018c5b3ad6761d294469173e9f628 =2D----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 ha= ck > > 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=20 see why a combination of --nodeps and --onlydeps on package x and y can't=20 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=20 ordering than already exists, but I can't be sure. Perhaps, the solution is= =20 to fix the dependency resolver then fix the packages and then enable parall= el=20 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 wa= y,=20 but I would suggest that the package depend on both kernel-headers and glib= c=20 for robustness in the tree. Unlikely in this case, but it ensures that a=20 change to glibc's dependencies don't break the packages that depend on it. Regards, Jason Stubbs =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQCVAwUBQN1Bh1oikN4/5jfsAQIn1AP+JpYCphzGsFLJlm6hnntLfGaJ+KWjjb61 UNR4sw7q/qRq4GfNliBfNetb16K6jjBRseZUrt9p5ofdjgu6nCxEyfl5F+0QyPSH sAZq0eqFcobARU+TUPGGBeJG82ve46BJDCTPF4ieK3dFm4/0sfRYHz+DAYQnNFG6 eq507/u1bRM=3D =3D3rkH =2D----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list