sön 2001-10-14 klockan 19.41 skrev Martin Schlemmer: > On Sun, 2001-10-14 at 18:41, Karl Trygve Kalleberg wrote: > > > Subterfuge functionality in Portage > > > > Subterfugue is a low-level system administration tool that can bar > > write access to directories, restrict download speed, inspect and act > > upon operating system level triggers, such as opening of files, > > creation of directories, consumption of memory and similar. > > It would be very beneficial to the Gentoo developers if Portage > > used some of the features of Subterfuge to create a sandbox for > > creating ebuilds > > Most specifically, Subterfuge could be used to ensure that no > > ebuild writes outside its image-directory. > > In addition, for people with slow links, it would be preferrable to > > specify a maximum bandwidth amount that Portage could use for > > downloading large tarballs. Although Subterfuge has the ability to > > dynamically change the allocated bandwidth, a simple entry in > > /etc/make.conf should suffice. Yes, this would be great! > > > > > > Sensible default configuations > > > > Only a miniscule subset of our daemons run straight out of the > > box. For many daemons, sensible (paranoid) defaults are fairly easy > > to set by the ebuild. > > Alternatively, we could start thinking about configuration > > profiles that can be applied to a set of applications. While we (and > > our users) really want to configure/tweak most aspects of all > > configurations files ourselves at some point, having a paranoid > > setting in the interim would be better than force the user to > > hastily put together a configuration that's full of holes. > > > > > > I am not one that installs many services, and usually just the basic > config file with commented options is sufficient for me. However, > we should relise that not only developers will use Gentoo Linux, > especially when version 1.0 is released. Then we will have to deal > with end users, and like Karl said, rather a safe, secure config, > then the wide open ones some other distro's have (wont mention names ;p) Disable everything not needed during installation. Close all ports and make the defaultinstallation unaccessable from net. > > Ebuild review upon commit > > > > Many of our ebuilds contain small oversights and suffers from not > > being tested enough. We should accept that fact that to err is human, > > and figure out a way to minimize the number of errors > > To that end, I propose we at some point institute a two-level > > checkin mechanism, even for developers. For any package to be > > unmasked (and thus readily available to end-users), at least one > > other developer must look through it and vouch for its > > stability. > > The proposal is not about assigning blame. It is about > > minimizing the number of errors. I personally try to have a few of > > the denizens on #gentoo test my ebuilds before committing and > > unmasking. > > > > > > Maybe create a Ebuild Team, who take over Dan's job of filtering ebuilds > to incoming. Also developers should mail updates/changes to > gentoo-ebuild, and these people test it first before it gest unmasked. > Guess this team dont have to be big, 1 or 2 people should sufficient for > now. Maybe just people with high speed connections (I know how long it > takes me to download on 56k ... usually way longer than creating the > ebuild). Hmm, while this might be needed in the future I don't think we have the capacity for this currently. We are about 10 active developers and the Gentoo development would more or less stop if this had to be done. Just look at how good we are at handling gentoo-ebuild now, if all developers has to mail there aswell nothing would go in. Regards, Mikael Hallendal > My own wishlist: Layout for a .ebuild Yes, we need a standard for layout on ebuilds. This is exactly as codingstandards in coding-projects. It's very important for maintainability. We need to write a document describing this and all developers has to follow this even if they might not like the syntax. I try to make all my ebuilds look the same and probably others try that aswell. One problem now is that no one knows who is responsible for which ebuilds. If we can't decide on a syntax for our ebuilds we have to make a list of who maintains which packages and after that people shouldn't commit on each others ebuilds. (I prefer the first way). Regards, Mikael Hallendal -- Mikael Hallendal Gentoo Linux Developer, Desktop Team Leader CodeFactory AB, Stockholm, Sweden