From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30466 invoked by uid 1002); 27 May 2003 01:40:20 -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 2939 invoked from network); 27 May 2003 01:40:20 -0000 Message-ID: <3ED2C203.7060902@gentoo.org> Date: Mon, 26 May 2003 18:40:19 -0700 From: Zach Welch Organization: Gentoo Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: gentoo-dev@gentoo.org References: <1053653430.29351.21.camel@mcvaio.liquidx.net> <20030526181230.GA6277%chutz@gg3.net> <1053973218.8263.28.camel@vader> <200305261149.36753.george@gentoo.org> <20030526192439.GB9995@time> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] common ebuild mistakes X-Archives-Salt: c7774418-ccb9-40e4-99e5-439d1540c4e7 X-Archives-Hash: 8ebb997f28ae9eee2745f7a190cd54ae Aron Griffis wrote: > George Shapovalov wrote:[Mon May 26 2003, 02:49:36PM EDT] > >> As such it makes sense to put some absolutely something basic in >> DEPEND for the package which does not have any apparent (as >> non-trivial, not bad-researched) dependencies. In that respect >> virtual/glibc perfectly fits the bill... > > > DEPEND="" works just as well. Since glibc is in the default profile, > there's no reason to list it as a dependency, just like we can > assume some basic shell utilities are present when the ebuild is > processed. > Depending on the degree you are talking here, I tend to disagree with the notion of not including some so call "basic" dependencies, because profiles can have variations that may include stripping out some core components. As we move into the embedded realm, the definition of our "core profile" will need to be reduced, so adding full dependency information now is not necessarily a bad thing. Instead, we need to clarify a truly minimal system set of packages (such as libc) for which their dependency information need not be included. This will probably be taken up as part of the embedded project's efforts to scale the system down, so there is not pressure to do this now. The tools already exists to build a dependecy list by tracking what the actual build process uses during execution, and I have seen a couple of ebuilds in the tree that seem to have used them. This may not be a bad standard practice to follow if those few core packages can be put on a 'whitelist' for exclusion by those tools. At some distant point, automating this process with a tool would not be a bad thing: emerge --makedeps package-1.0.ebuild This would build the package, tracking the deps, and modifying the ebuild to update the build dependencies. The recent thread that talked about collecting branch prediction information by automatically running the program a few times suggests to me that a similar process could be applied to also detect RDEPENDS. The above flag should also imply the use of --digest run as a finalization step. Cheers, Zach Welch Gentoo Embedded Lead Superlucidity Services -- gentoo-dev@gentoo.org mailing list