Gentoo Archives: gentoo-dev

From: Vitaly Kushneriuk <vitaly@×××××.com>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] New ideas, USE database, sandbox & more
Date: Mon, 03 Dec 2001 06:56:41
Message-Id: 1007384145.9501.8.camel@uranus.u235.eyep.net
In Reply to: Re: [gentoo-dev] New ideas, USE database, sandbox & more by Geert Bevin
1 > The problem with long descriptions is that they should be updated
2 > consistantly. Also, package authors tend to neglect them. It's a useful
3 > addition, but I can only see it usefulness if some sort of graphical
4 > package manager were available.
5 >
6
7 Not realy. I'd like to be able to get some more information
8 about any of the ebuilds in /usr/portage. Like:
9 [/root]# emerge --whatis gcc
10 Summary : Various compilers (C, C++, Objective-C, ...)
11 Description :
12 A compiler aimed at integrating all the optimizations and features
13 necessary for a high-performance and stable development
14 environment. You'll need this package in order to compile C/C++ code.
15 [/root]#
16
17 The description may be a SEPARATE file, so that future ebuilds for
18 the same package will use just latest description file available
19
20 > > 6)Why bother with the sendbox and not just compile and install nonroot?
21 > > Some packages will even refuse to be built by root. Take a look at
22 > > rpm build system. Any reasonably good srpm will compile as non root.
23 >
24 > Because non-root and sandbox work together. There are also a number of
25 > ebuilds that need to be root before being able to install. Working in
26 > non root fixes the access right to paths statically. A sandbox does this
27 > dynamically, offering a much more flexible environment. Some ebuilds
28 > need also to be able to switch to other users and perform initialization
29 > as the other user. A nice feature of the sandbox is that additionally to
30 > portage, the ebuild package system can be used to create much more
31 > complex personal packages. For example, we have ebuilds for each of our
32 > clients and projects, automating installing and configuration. I
33 > certainly don't want any files of one client installation to 'leak'
34 > accidentally into common ground or even worse, into another's
35 > installation. Using the sandbox its possible to change the allowed path
36 > for each package (and even during the ebuild) and offer that kind of
37 > protection.
38 Entire binary distributions compile as non root, so I think it should
39 not be a problem. To prevent "leaking" of files, just set up reasonable
40 access rigts, then run as user, and you'll not be able to write to
41 other user directory etc. Then , again, Portage should not be
42 MOST-GENERIC-kNOW-HOW-TO-BUILD-EVERYTHING-COOLEST-THING-IN-THE-WORLD :-)
43 It's just a tool to compile Linux system and keep it up to date.
44 It should not be over complicated to support every wierd configuration.
45 Things like you described sound like more suitable
46 task for "make" or "cook" :-)
47 We better make Portage more usable for all SAs, which includes much
48 simplified ebuild creation. With some effort, we can make it build from
49 a little "rewriten" rpm spec file, which can be
50 extracted from any binary distro. So that if you see some new cool
51 proggy, providing rpm download, or just a plain spec inside the tgz.
52 It will take only few minutes to convert it to Portage format and build.
53
54
55 Regards,
56 Vitaly.