1 |
Hi gang. |
2 |
|
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 :) |
7 |
|
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]). |
13 |
|
14 |
Anyway, here follows: |
15 |
|
16 |
|
17 |
|
18 |
Gentoo Linux Wishlist |
19 |
|
20 |
Karl Trygve Kalleberg |
21 |
|
22 |
|
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. |
27 |
|
28 |
|
29 |
1.0 |
30 |
2001-10-13 |
31 |
|
32 |
|
33 |
The unsorted items |
34 |
|
35 |
|
36 |
Gentool.Configure |
37 |
|
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. |
60 |
|
61 |
|
62 |
|
63 |
|
64 |
Subterfuge functionality in Portage |
65 |
|
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. |
80 |
|
81 |
|
82 |
|
83 |
|
84 |
Sensible default configuations |
85 |
|
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. |
95 |
|
96 |
|
97 |
|
98 |
|
99 |
Ebuild review upon commit |
100 |
|
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. |
113 |
|
114 |
|
115 |
|
116 |
|
117 |
|
118 |
The prioritized items |
119 |
|
120 |
|
121 |
|
122 |
The rejected items |