Gentoo Archives: gentoo-dev

From: Mikael Hallendal <hallski@g.o>
To: gentoo-dev@××××××××××.org
Subject: Re: [gentoo-dev] A wishlist
Date: Tue, 16 Oct 2001 05:11:59
Message-Id: 1003238060.8487.27.camel@zoidberg
In Reply to: Re: [gentoo-dev] A wishlist by Martin Schlemmer
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

Replies

Subject Author
Re: [gentoo-dev] A wishlist Joshua Pierre <joshua@×××××.com>
[gentoo-dev] rc6 "bash:mc" Mark King <fires10@×××××.com>