From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vitaly@jungo.com>
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 20086189BD
	for <gentoo-dev@gentoo.org>; Mon,  3 Dec 2001 06:56:41 -0600 (CST)
Received: (qmail 15993 invoked by uid 500); 3 Dec 2001 12:55:45 -0000
Subject: Re: [gentoo-dev] New ideas, USE database, sandbox & more
From: Vitaly Kushneriuk <vitaly@jungo.com>
To: gentoo-dev@gentoo.org
In-Reply-To: <1007380157.1252.0.camel@willow>
References: <003f01c17bcd$ed380c30$6400a8c0@server> 
	<1007379134.13527.5.camel@uranus.u235.eyep.net> 
	<1007380157.1252.0.camel@willow>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.99.0 (Preview Release)
Date: 03 Dec 2001 14:55:45 +0200
Message-Id: <1007384145.9501.8.camel@uranus.u235.eyep.net>
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: <mailto:gentoo-dev-request@gentoo.org?subject=help>
List-Post: <mailto:gentoo-dev@gentoo.org>
List-Subscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>,
	<mailto:gentoo-dev-request@gentoo.org?subject=subscribe>
List-Id: Developer discussion list <gentoo-dev.gentoo.org>
List-Unsubscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>,
	<mailto:gentoo-dev-request@gentoo.org?subject=unsubscribe>
List-Archive: <http://lists.gentoo.org/pipermail/gentoo-dev/>
X-Archives-Salt: f0c16297-164f-4caa-8670-cc27f47f483b
X-Archives-Hash: e419d7a7629f2dc7af23c4b8335aa909

 
> 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.
>

Not realy. I'd like to be able to get some more information
about any of the ebuilds in /usr/portage. Like:
[/root]# emerge --whatis gcc
Summary     : Various compilers (C, C++, Objective-C, ...)
Description :
A compiler aimed at integrating all the optimizations and features
necessary for a high-performance and stable development
environment. You'll need this package in order to compile C/C++ code.
[/root]#

The description may be a SEPARATE file, so that future ebuilds for
the same package will use just latest description file available

> > 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.
Entire binary distributions compile as non root, so I think it should
not be a problem. To prevent "leaking" of files, just set up reasonable 
access rigts, then run as user, and you'll not be able to write to
other user directory etc. Then , again, Portage should not be 
MOST-GENERIC-kNOW-HOW-TO-BUILD-EVERYTHING-COOLEST-THING-IN-THE-WORLD :-)
It's just a tool to compile Linux system and keep it up to date.
It should not be over complicated to support every wierd configuration.
Things like you described sound like more suitable
task for "make" or "cook" :-)
We better make Portage more usable for all SAs, which includes much
simplified ebuild creation. With some effort, we can make it build from
a little "rewriten" rpm spec file, which can be 
extracted from any binary distro. So that if you see some new cool
proggy, providing rpm download, or just a plain spec inside the tgz.
It will take only few minutes to convert it to Portage format and build.


Regards,
	Vitaly.