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=1.2 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, RDNS_NONE autolearn=no autolearn_force=no version=4.0.0 Received: from uranus.u235.eyep.net (unknown [194.90.113.98]) by chiba.3jane.net (Postfix) with SMTP id 4851018993 for ; Mon, 3 Dec 2001 05:33:18 -0600 (CST) Received: (qmail 4822 invoked by uid 500); 3 Dec 2001 11:32:14 -0000 From: Vitaly Kushneriuk To: gentoo-dev@gentoo.org In-Reply-To: <003f01c17bcd$ed380c30$6400a8c0@server> References: <003f01c17bcd$ed380c30$6400a8c0@server> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 03 Dec 2001 13:32:13 +0200 Message-Id: <1007379134.13527.5.camel@uranus.u235.eyep.net> Mime-Version: 1.0 Subject: [gentoo-dev] New ideas, USE database, sandbox & more 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: 60f8d44e-85cb-49f9-8ce7-cf4d18fc7ec9 X-Archives-Hash: d31765b744619fd35381d8958ccf62a7 On Mon, 2001-12-03 at 09:41, Sebastian Werner wrote: > Hey, > > I like your idea. I have the same problems with the many variables I > could set. Some other idea I think could be good is to store the data > with gconf or something else (a binary registry - like windows but > better). > > Sebastian Werner I like the idea too, but I don't think we should use gconf. This information should be stored in clear text for easy inspection/editing. Some more ideas: Note before I start: I can participate in development of my proposals, but I want to be sure that you guys like the ideas. Please comment... 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. 2)Long descriptions should be added. 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. 7)And while we at it, why not using rpm as underlying package system with Portage metadata added to the rpm file. Yes, I know, rpm is considered "evil" by many linux hackers alike. I don't see a real reason why. If rpm complains about some dependency stuff, you can allways run "rpm --force --nodeps" to make it look like just a tarball. Still there must be a reason why it complains, so some action should be taken (i.e. other package removed/recompiled etc), and that exectly what Portage can take care of. And, btw, rpm config file protection is realy great. ( well, we can do the same in Portage, but why reinvent the wheel?) And yes, I VERY like to type 'rpm -qf ' to know which package installed this file. While an average Gentoo admin knows her system better then an admin using binary distribution, it's impossible/impractical to know EVERY file on the system. And this is only one of the many useful rpm queries I'm used to like. So here how I see the integration: * Compilation and installation are performed as usual su'ed to some "build" user (see 6). * All Portage metadata is "installed" into /var/db No need for CONTENTS/CATEGORY/LICENSE/PROVIDE/RDEPEND * src_files() function is called to generate rpm %files list. auto_files() function called from default src_files() will scan install root directory and prepend all files in /etc with %conf, and all files in */doc/, */man/ or */info/ with %doc. Well, actualy some configurable list can be used for config directories. If, for some package, this function fails for some file, the package files() function can easily fix it by something like: echo %defattr(-, bin, bin) auto_files | grep -v 'myconfig' | grep -v devattr echo %conf %attr(-, bin, wheel) /mydir/myconfig I have auto_file implementation I used to build rpms when I used RedHat. * spec file is generated ( we allready have that ) and all the files packaged into rpm ( in future versions we even can create rpm directly using rpmlib api ) * rpm package is installed by "rpm -Uvh" This is the ONLY stage performed as root.