From: Geert Bevin <gbevin@theleaf.be>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] New ideas, USE database, sandbox & more
Date: 03 Dec 2001 12:48:59 +0100 [thread overview]
Message-ID: <1007380157.1252.0.camel@willow> (raw)
In-Reply-To: <1007379134.13527.5.camel@uranus.u235.eyep.net>
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@theleaf.be Tel & Fax +32 2 241 19 98
next prev parent reply other threads:[~2001-12-03 11:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-03 1:06 [gentoo-dev] USE database? Zach Forrest
2001-12-03 7:41 ` AW: " Sebastian Werner
2001-12-03 9:13 ` Geert Bevin
2001-12-03 10:02 ` AW: " Sebastian Werner
2001-12-03 10:12 ` Geert Bevin
2001-12-03 11:05 ` AW: " Sebastian Werner
2001-12-03 11:05 ` Geert Bevin
2001-12-03 11:26 ` AW: " Sebastian Werner
2001-12-03 11:32 ` [gentoo-dev] New ideas, USE database, sandbox & more Vitaly Kushneriuk
2001-12-03 11:48 ` Geert Bevin [this message]
2001-12-03 12:55 ` Vitaly Kushneriuk
2001-12-03 14:01 ` Joshua Pierre
2001-12-03 16:06 ` Vitaly Kushneriuk
2001-12-03 16:28 ` Daniel Robbins
2001-12-03 18:00 ` Vitaly Kushneriuk
2001-12-03 16:48 ` [gentoo-dev] USE database? Daniel Robbins
2001-12-06 6:01 ` Mikael Hallendal
2001-12-06 18:12 ` Zach Forrest
2001-12-06 20:38 ` Mikael Hallendal
2001-12-06 22:33 ` Zach Forrest
2001-12-06 23:40 ` Daniel Robbins
2001-12-06 23:52 ` Zach Forrest
2001-12-07 19:28 ` Sebastian Werner
2001-12-07 21:39 ` Daniel Robbins
2001-12-07 21:43 ` Geert Bevin
2001-12-08 1:44 ` Mikael Hallendal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1007380157.1252.0.camel@willow \
--to=gbevin@theleaf.be \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox