Gentoo Archives: gentoo-dev

From: Karl Trygve Kalleberg <karltk@×××××××.no>
To: gentoo-dev@g.o
Subject: [gentoo-dev] A wishlist
Date: Sun, 14 Oct 2001 10:41:58
1 Hi gang.
3 Lukewarm on the heels of my last post about things that should be in place
4 before 1.0, I now come with a non-triaged wishlist that are mostly my own
5 wishes. If there's anything smart in what follows, that's probably due to
6 pekdon and/or Azarah :)
8 (If you think the formatting looks like shit, it's because it is. I've
9 written this as a Gentoo Guide, since I plan on maintaining it as web
10 document on our site. We do not currently seem to have an XSL that
11 transforms our guides to pure text [and the html converter also leaves a
12 lot to be desired]).
14 Anyway, here follows:
18 Gentoo Linux Wishlist
20 Karl Trygve Kalleberg
23 This document maintains a prioritized list of features which Gentoo
24 Linux will have (and not have) in the near and middle future. The list
25 is posted semi-regularily to the developers' list, where new items are
26 proposed, prioritized or rejected.
29 1.0
30 2001-10-13
33 The unsorted items
36 Gentool.Configure
38 Currently, Gentool is (not being) maintained by karltk. Its goal
39 is to act as an entry point into portage proper for fancy things that
40 we want to have in our package management system.
41 I suggest we rename Gentool into Gentools and rather make it into
42 a collection of scripts with common syntax/semantics. It could then
43 easily evolve into the Gentoo configuration toolset that handled
44 user management, daemon management, hardware managment, etc,
45 without being imposed on each user.
46 Currently, I suggest the following tools:
47 gentool.daemonlist: Lists running and runnable daemons.
48 gentool.driverlist: Lists the running subsystems. For some
49 machines, most notably portables, it is desirable to turn off
50 subsystems that are not in use to conserve battery power. irda, cdrom,
51 usb, sound, network/cardbus are examples of this.
52 gentool.depends: Lists packages depending on a particular
53 package.
54 I realise that this is currently more a collection of inspection
55 tools than configuration tools, but I find myself lacking information
56 about the packages far too often, ie which package do I have to
57 install to get Java ?, which package contains xsltproc ?,
58 etc. Sometimes, a simple grep through the ebuilds suffice, other
59 times a complex search with google is the only way.
64 Subterfuge functionality in Portage
66 Subterfugue is a low-level system administration tool that can bar
67 write access to directories, restrict download speed, inspect and act
68 upon operating system level triggers, such as opening of files,
69 creation of directories, consumption of memory and similar.
70 It would be very beneficial to the Gentoo developers if Portage
71 used some of the features of Subterfuge to create a sandbox for
72 creating ebuilds
73 Most specifically, Subterfuge could be used to ensure that no
74 ebuild writes outside its image-directory.
75 In addition, for people with slow links, it would be preferrable to
76 specify a maximum bandwidth amount that Portage could use for
77 downloading large tarballs. Although Subterfuge has the ability to
78 dynamically change the allocated bandwidth, a simple entry in
79 /etc/make.conf should suffice.
84 Sensible default configuations
86 Only a miniscule subset of our daemons run straight out of the
87 box. For many daemons, sensible (paranoid) defaults are fairly easy
88 to set by the ebuild.
89 Alternatively, we could start thinking about configuration
90 profiles that can be applied to a set of applications. While we (and
91 our users) really want to configure/tweak most aspects of all
92 configurations files ourselves at some point, having a paranoid
93 setting in the interim would be better than force the user to
94 hastily put together a configuration that's full of holes.
99 Ebuild review upon commit
101 Many of our ebuilds contain small oversights and suffers from not
102 being tested enough. We should accept that fact that to err is human,
103 and figure out a way to minimize the number of errors
104 To that end, I propose we at some point institute a two-level
105 checkin mechanism, even for developers. For any package to be
106 unmasked (and thus readily available to end-users), at least one
107 other developer must look through it and vouch for its
108 stability.
109 The proposal is not about assigning blame. It is about
110 minimizing the number of errors. I personally try to have a few of
111 the denizens on #gentoo test my ebuilds before committing and
112 unmasking.
118 The prioritized items
122 The rejected items


Subject Author
Re: [gentoo-dev] A wishlist Martin Schlemmer <azarah@g.o>
Re: [gentoo-dev] A wishlist Dan Armak <danarmak@g.o>
Re: [gentoo-dev] A wishlist Dan Armak <danarmak@g.o>
Re: [gentoo-dev] A wishlist Joshua Pierre <joshua@×××××.com>