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