[gentoo-dev] A wishlist

[Karl Trygve Kalleberg <karltk@prosalg.no>]

Hi gang.

Lukewarm on the heels of my last post about things that should be in place
before 1.0, I now come with a non-triaged wishlist that are mostly my own
wishes. If there's anything smart in what follows, that's probably due to
pekdon and/or Azarah :)

(If you think the formatting looks like shit, it's because it is. I've
written this as a Gentoo Guide, since I plan on maintaining it as web
document on our site. We do not currently seem to have an XSL that
transforms our guides to pure text [and the html converter also leaves a
lot to be desired]).

Anyway, here follows:



Gentoo Linux Wishlist

  Karl Trygve Kalleberg


This document maintains a prioritized list of features which Gentoo
Linux will have (and not have) in the near and middle future. The list
is posted semi-regularily to the developers' list, where new items are
proposed, prioritized or rejected. 


1.0
2001-10-13


The unsorted items


 Gentool.Configure
 
 Currently, Gentool is (not being) maintained by karltk. Its goal
 is to act as an entry point into portage proper for fancy things that
 we want to have in our package management system.
 I suggest we rename Gentool into Gentools and rather make it into
 a collection of scripts with common syntax/semantics. It could then 
 easily evolve into the Gentoo configuration toolset that handled
 user management, daemon management, hardware managment, etc,
 without being imposed on each user.
 Currently, I suggest the following tools:
 gentool.daemonlist: Lists running and runnable daemons.
 gentool.driverlist: Lists the running subsystems. For some
 machines, most notably portables, it is desirable to turn off
 subsystems that are not in use to conserve battery power. irda, cdrom,
 usb, sound, network/cardbus are examples of this.
 gentool.depends: Lists packages depending on a particular 
 package.
 I realise that this is currently more a collection of inspection
 tools than configuration tools, but I find myself lacking information
 about the packages far too often, ie which package do I have to
 install to get Java ?, which package contains xsltproc ?,
 etc. Sometimes, a simple grep through the ebuilds suffice, other
 times a complex search with google is the only way. 
 



 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.
 



 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.
 



 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.
 




The prioritized items



The rejected items