Re: [gentoo-dev] Some suggestions

[Marius Mauch]

On 09/06/03  David Sankel wrote:

> Hello gentoo developers,
>
>   I would like to say great job to all of you.  Gentoo is an
>   exceptional
> distribution.  I have been using it for about 7 months now.  You all
> should be very proud of yourselves for creating a very solid software
> product.
>
>   I am an independent contractor with several years experience in user
> interaction with software systems.  I came up with a few suggestions
> for the gentoo system.  It is my hope that you will find them
> interesting or informative.
>
> 1)  etc-update changes for a more automated system update
>
> etc-update allows you to automatically update (noted) etc files that
> one never changed from their last emerge.  This could save a lot of
> maintenance time if it was put in a cron job to routinely do that
> after an "emerge sync;emerge -u world"
>   The user then wouldn't have to look at all of the etc files to see
> if they were changed after every "emerge sync; emerge-u world".

You don't really use emerge -u world in a cron job? emerge -u world and
etc-update can bring severe changes to your system and might create
problems if used without caution, so I strongly discourage anyone from
running them in a cron-job.
But I agree that etc-update needs some improvements, haven't looked at
dispatch-conf yet, maybe it does the job better.

> 2)  make.conf updates to be more automated
>
> Most gentoo users, I believe, modify this file.  This specific file
> changes quite often with updates.  Since most users only modify the
> "USE" and "CFLAGS" components, having an update that is automatic is
> plausible.  This feature is a trade off between the integrity and
> consistency of the system verses end-user maintenance time.

make.conf updates are annoying, maybe we can make an exception in
etc-update for it to handle it different (only look for new variables).

> 3) emerge -u world "NOTICE:" output changes.
>
> When doing an "emerge -u world" several "NOTICE:"'s fly by on the
> screen. For many users, they go unread although they contain important
> information in a lot of cases.  If these "NOTICE:"'s are cached and
> output at the end of an "emerge -u world", their readership would have
> a dramatic increase. This would allow interested gentoo users to be
> more informed of their system.

There are several bugs open about this.

> 4) emerge -u world progress bar option
>
> Most users probably care less about the compilation stages of their
> update in comparison to the percentage of completion.  A progress bar
> in this area would be a nice aesthetic and informative addition for
> most users. In order for this to happen, the output of the "emerge -u
> world" command would probably have to be standardized with some flags
> to mark the beginning and end of a compile.

A accurate progress bar is nearly impossible as compile times differ
from package to package (and are independent of package size too). The
only thing that would be rather easy to implement is a progrssbar that
only advance when a package is finished and even then we need something
to keep it on the screen, so ncurses or something similar would be
needed.

> 5) A simple graphical front end to maintenance commands such as
> "emerge sync", "emerge -u world", and "etc-update".

kportage, portagemaster and there are several others not in the tree
yet.
 
> It would be a nice feature if users didn't have to commit these
> commands to memory for regular maintenance.  The maintenance menu
> might have an icon on all of the default desktops.  If this type of
> program was implemented, it could be prominently displayed and made
> known for all new users.  Perhaps the install documentation could use
> this tool as much as possible.

I disagree, every user should know the basic system management commands.
We really should not rely on GUI tools. It would just add another
possible point of failure.

> 6) A streamlined GUI install.
>
> I'm sure this one has been brought up before.  I consider this the
> "1.0" maker of the gentoo distribution.  In such an installer, I
> suggest that the CFLAGS should not be modified by default.  It has
> been shown in several places that optimizing these does not give a
> significant enough performance increase.  It should stay, of course,
> as an option though.

Most people (including me) don't like that, there are other distros for
that. One approach I like is glis (gentoo linux install script), beause
it doesn't dumb down the install process.
Search the forums, there are several threads about this issue.

> 7) Emerge -S and Emerge -s speed improvements.
>
> I don't know why these commands perform as slow as they do.  My
> intuition says that they could be an order of magnitude faster.
> Perhaps a reimplementation in C/C++ or a data format change could
> help.

They are slow because they have to access several thousand files. Search
the forums or bugzilla for esearch, that is a script using a static
index to improve search times to about one second.
A rewrite in C/C++ would only cost a lot of time and won't bring much in
terms of speed (this has come up several times). One thing that has some
potential to improve the speed is to use a database for the portage
tree, but that won't happen anytime soon. There is the portagesql
project at breakmygentoo.net that tries to achieve such a solution,
haven't tried it yet.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.