From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, RDNS_DYNAMIC autolearn=no autolearn_force=no version=4.0.0 Received: from lark.theleaf.office (cable-213-132-142-63.upc.chello.be [213.132.142.63]) by chiba.3jane.net (Postfix) with SMTP id 99C001899B for ; Mon, 3 Dec 2001 05:49:50 -0600 (CST) Received: (qmail 19138 invoked from network); 3 Dec 2001 11:48:17 -0000 Received: from unknown (HELO willow.theleaf.office) (10.1.1.3) by 10.1.1.1 with SMTP; 3 Dec 2001 11:48:17 -0000 Subject: Re: [gentoo-dev] New ideas, USE database, sandbox & more From: Geert Bevin To: gentoo-dev@gentoo.org In-Reply-To: <1007379134.13527.5.camel@uranus.u235.eyep.net> References: <003f01c17bcd$ed380c30$6400a8c0@server> <1007379134.13527.5.camel@uranus.u235.eyep.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 03 Dec 2001 12:48:59 +0100 Message-Id: <1007380157.1252.0.camel@willow> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Developer discussion list List-Unsubscribe: , List-Archive: X-Archives-Salt: 227739a7-fd22-4dfb-9ece-a7f4b22ff09e X-Archives-Hash: 3bebbc28011b586e2c5e18642309a026 On Mon, 2001-12-03 at 12:32, Vitaly Kushneriuk wrote: > 1)Actualy used features should be stored ,so that if > I install a package which can use FEATURE1 and FEATURE2, but > only FEATURE1 is available(and used) at the build time, I'd like to be > notified when I install another package that provides FEATURE2, that > I can remerge the first package for additional functionality. > As all USES available during build are already stored in /var/db > We only need to add list of possible USES in .ebuild. I like the idea of feature provision notification. > 2)Long descriptions should be added. The problem with long descriptions is that they should be updated consistantly. Also, package authors tend to neglect them. It's a useful addition, but I can only see it usefulness if some sort of graphical package manager were available. > 3)emerge should search for package in category dirs. So that > "emerge gcc" as "emerge sys-devel/gcc" > > 4)ebuilds must be simplified! Most packages can be build by rpm macros > > %setup > %configure > %make > %makeinstall > > We should provide such macros for our builds and use them in the > default implementation for unpack/compile/install functions. > So that most ebuilds will contain only URL/DESCRIPTION etc. > > 5)Compile and install logs should be stored for future inspection. > Should be realy simple to implement. Just redirect sub shell to > "| tee . Or even "> logfilename" if emerge called with > --silent flag. > > 6)Why bother with the sendbox and not just compile and install nonroot? > Some packages will even refuse to be built by root. Take a look at > rpm build system. Any reasonably good srpm will compile as non root. Because non-root and sandbox work together. There are also a number of ebuilds that need to be root before being able to install. Working in non root fixes the access right to paths statically. A sandbox does this dynamically, offering a much more flexible environment. Some ebuilds need also to be able to switch to other users and perform initialization as the other user. A nice feature of the sandbox is that additionally to portage, the ebuild package system can be used to create much more complex personal packages. For example, we have ebuilds for each of our clients and projects, automating installing and configuration. I certainly don't want any files of one client installation to 'leak' accidentally into common ground or even worse, into another's installation. Using the sandbox its possible to change the allowed path for each package (and even during the ebuild) and offer that kind of protection. -- Geert Bevin the Leaf sprl/bvba "Use what you need" Pierre Theunisstraat 1/47 http://www.theleaf.be 1030 Brussels gbevin@theleaf.be Tel & Fax +32 2 241 19 98