Re: [gentoo-dev] New ideas, USE database, sandbox & more

[Geert Bevin]

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 <logfilename>. 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@×××××××.be             Tel & Fax [phone]