Re: [gentoo-dev] A wishlist

[Martin Schlemmer]

On Sun, 2001-10-14 at 18:41, Karl Trygve Kalleberg wrote:
>
> 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.
>
>

Gui/scripts that control the whole system, or just show info will be
nice, but I think some docs on the whole init system and maybe a 
long checkup/fixup/reimplementation to it will be nice.

Look at /etc/modules.autoload (or whatever).  From what I have heard,
it is supposed to replace /etc/modules for autoloading of modules.
Thing just is, I cant find it being parsed anywhere (/etc/init.d/modules
parse /etc/modules and /etc/modules.d).

Yes, these tools will be nice, but I think we need to checkup on the
basesystem first, fix it up, add features, and MOST IMPORTANTLY, 
DOCUMENT IT!  Only then will these tools be of use, otherwise it 
will have to be modified whenever problems with the initsystem is
descoverd and changed.
 
>
>
>  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!  I am _very_ in favour of this.  With all the different ways to
./configure and install source out there, it is very difficult to
ensure that all files is installed in ${D}, and even after reading
the Makefile's install: section, you can still miss something.
A feature that will monitor file/directory creation during 
src_install() will be a major improvement.  On a file that gets
installed outside ${D}, portage should quit, and give an error with
the offending file/directory.

>
>
>  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)


>
>
>  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).


And yes, it is not assigning blame, but what works on your system,
could be broken on another system.
 
>
>
>
> The prioritized items
>
>
>
> The rejected items
>
>

My own wishlist:  Layout for a .ebuild

Especially with the gnome move to /usr, I had to modify a LOT of
ebuilds.  And usually not two's form was the same (even with the
same author).  

Main points this form should touch (my opinion of course ;-):

1) Lay out the musts and must nots for a ebuild.  The ${A} issue
etc.

2) Explain some of the hidden features that I have to find out
by hacking lots of other ebuilds.

3) Have a Changelog ... things that worked one way, now a different way.
Not nice to have used something, then next time find out it changed.

4) Neatness.  Go into how the form of NEAT ebuild should be.  You
must remember that with every ebuild, you are creating a building
block that others will build apon ....

5) Upgradebility.  Any Ebuild should be able to just be copied to the
new version, and then work out of the box (excluding compile errors).
I think the mplayer ebuild is a nice example of this, it will work for
release and pre versions.  The VIM ebuild is another example.

6) Everything else i forgot.



I am no doc writer, so excuse if not too clear.


Greetings

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa
Town, South Africa