1 |
sön 2001-10-14 klockan 19.41 skrev Martin Schlemmer: |
2 |
> On Sun, 2001-10-14 at 18:41, Karl Trygve Kalleberg wrote: |
3 |
> |
4 |
> > Subterfuge functionality in Portage |
5 |
> > |
6 |
> > Subterfugue is a low-level system administration tool that can bar |
7 |
> > write access to directories, restrict download speed, inspect and act |
8 |
> > upon operating system level triggers, such as opening of files, |
9 |
> > creation of directories, consumption of memory and similar. |
10 |
> > It would be very beneficial to the Gentoo developers if Portage |
11 |
> > used some of the features of Subterfuge to create a sandbox for |
12 |
> > creating ebuilds |
13 |
> > Most specifically, Subterfuge could be used to ensure that no |
14 |
> > ebuild writes outside its image-directory. |
15 |
> > In addition, for people with slow links, it would be preferrable to |
16 |
> > specify a maximum bandwidth amount that Portage could use for |
17 |
> > downloading large tarballs. Although Subterfuge has the ability to |
18 |
> > dynamically change the allocated bandwidth, a simple entry in |
19 |
> > /etc/make.conf should suffice. |
20 |
|
21 |
Yes, this would be great! |
22 |
|
23 |
> > |
24 |
> > |
25 |
> > Sensible default configuations |
26 |
> > |
27 |
> > Only a miniscule subset of our daemons run straight out of the |
28 |
> > box. For many daemons, sensible (paranoid) defaults are fairly easy |
29 |
> > to set by the ebuild. |
30 |
> > Alternatively, we could start thinking about configuration |
31 |
> > profiles that can be applied to a set of applications. While we (and |
32 |
> > our users) really want to configure/tweak most aspects of all |
33 |
> > configurations files ourselves at some point, having a paranoid |
34 |
> > setting in the interim would be better than force the user to |
35 |
> > hastily put together a configuration that's full of holes. |
36 |
> > |
37 |
> > |
38 |
> |
39 |
> I am not one that installs many services, and usually just the basic |
40 |
> config file with commented options is sufficient for me. However, |
41 |
> we should relise that not only developers will use Gentoo Linux, |
42 |
> especially when version 1.0 is released. Then we will have to deal |
43 |
> with end users, and like Karl said, rather a safe, secure config, |
44 |
> then the wide open ones some other distro's have (wont mention names ;p) |
45 |
|
46 |
Disable everything not needed during installation. Close all ports and |
47 |
make the defaultinstallation unaccessable from net. |
48 |
|
49 |
> > Ebuild review upon commit |
50 |
> > |
51 |
> > Many of our ebuilds contain small oversights and suffers from not |
52 |
> > being tested enough. We should accept that fact that to err is human, |
53 |
> > and figure out a way to minimize the number of errors |
54 |
> > To that end, I propose we at some point institute a two-level |
55 |
> > checkin mechanism, even for developers. For any package to be |
56 |
> > unmasked (and thus readily available to end-users), at least one |
57 |
> > other developer must look through it and vouch for its |
58 |
> > stability. |
59 |
> > The proposal is not about assigning blame. It is about |
60 |
> > minimizing the number of errors. I personally try to have a few of |
61 |
> > the denizens on #gentoo test my ebuilds before committing and |
62 |
> > unmasking. |
63 |
> > |
64 |
> > |
65 |
> |
66 |
> Maybe create a Ebuild Team, who take over Dan's job of filtering ebuilds |
67 |
> to incoming. Also developers should mail updates/changes to |
68 |
> gentoo-ebuild, and these people test it first before it gest unmasked. |
69 |
> Guess this team dont have to be big, 1 or 2 people should sufficient for |
70 |
> now. Maybe just people with high speed connections (I know how long it |
71 |
> takes me to download on 56k ... usually way longer than creating the |
72 |
> ebuild). |
73 |
|
74 |
Hmm, while this might be needed in the future I don't think we have the |
75 |
capacity for this currently. We are about 10 active developers and the |
76 |
Gentoo development would more or less stop if this had to be done. Just |
77 |
look at how good we are at handling gentoo-ebuild now, if all developers |
78 |
has to mail there aswell nothing would go in. |
79 |
|
80 |
Regards, |
81 |
Mikael Hallendal |
82 |
|
83 |
> My own wishlist: Layout for a .ebuild |
84 |
|
85 |
Yes, we need a standard for layout on ebuilds. This is exactly as |
86 |
codingstandards in coding-projects. It's very important for |
87 |
maintainability. |
88 |
|
89 |
We need to write a document describing this and all developers has to |
90 |
follow this even if they might not like the syntax. |
91 |
|
92 |
I try to make all my ebuilds look the same and probably others try that |
93 |
aswell. One problem now is that no one knows who is responsible for |
94 |
which ebuilds. |
95 |
|
96 |
If we can't decide on a syntax for our ebuilds we have to make a list of |
97 |
who maintains which packages and after that people shouldn't commit on |
98 |
each others ebuilds. (I prefer the first way). |
99 |
|
100 |
Regards, |
101 |
Mikael Hallendal |
102 |
|
103 |
-- |
104 |
|
105 |
Mikael Hallendal |
106 |
Gentoo Linux Developer, Desktop Team Leader |
107 |
CodeFactory AB, Stockholm, Sweden |