Re: [gentoo-dev] Some suggestions (SUMMARY?)

[Jason Stubbs]

I'm just a user, not even running a server with Gentoo. My thoughts on your 
suggestions are aligned with most of the devs on almost every point, so I'll 
put my own thoughts and add relevant bits from other threads.

On Sunday 07 September 2003 03:05, David Sankel wrote:
> 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".

I've had this same idea myself. It should be fairly easy to do given 
/var/db/pkg/*/*/CONTENTS - that's got the modification date/time in there 
encoded, right?

A python script to address this issue named dispatch-conf has been written and 
is already included in sys-apps/portage. Details can be found at 
http://bugs.gentoo.org/show_bug.cgi?id=14079.

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

Personally, I'm against automatic updates of make.conf, the main reason being 
that important updates to portage's functionality are usually documented 
there (eventually). While some users would like this functionality, the work 
to implement it does not match the benefit.

Functionality such as this would belong in a (optional!) script that would be 
able to update all configuration files. That sort of thing would be way down 
the track, though. My reasoning on this is that automatic updates of 
make.conf should only be necessary for the layman whom would have trouble 
updating almost any configuration file. Presently, Gentoo does not support 
this class of user.

> 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 is a patch to portage available at 
http://bugs.gentoo.org/show_bug.cgi?id=11359. Once all the bugs are worked 
out, integration into official portage is likely.

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

There are two attempts at this at 
http://forums.gentoo.org/viewtopic.php?t=42346 and 
. Both are buggy and work does not seem to be continuing.

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

There is fairly full-featured work done on this already. Two packages for kde 
are app-portage/kemerge and app-portage/kportage. There is also one in java - 
app-portage/portagemaster. I believe there to be work done on a gnome 
front-end but I cannot find it in portage.

As to having it on the desktop by default, this is definately out of line with 
Gentoo's philosophy - Gentoo would have to make a decision for the user. 
There are also some technical aspects; some WMs don't even have a desktop, 
many installations don't have X11, etc.

Slightly unrelated but work is being done on a (optional!) unified menu 
system. Once that is completed, an emerge of one of the above portage 
front-ends would add an icon to the menus of all installed WMs. That is about 
the closest you'll ever get to a default desktop icon.

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

http://glis.sourceforge.net/
A mostly complete and bug-free curses version has already been written. The 
project is now undergoing a code restructuring to allow for easy rewriting of 
the front-end so that an X11 version can be written as well.

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

This has been discussed many times. Faster implementations can be found at 
http://bugs.gentoo.org/show_bug.cgi?id=24756 or
http://gentoo.devel-net.org/download/emerge-fastsearch.patch

"emerge esearch" was also suggested but I cannot find any information on it.

Portage is currently undergoing a rewrite to allow for pluggable back-ends. 
DB-based backends will address problems such as these. For a current DB-based 
portage, check portagesql as breakmygentoo.net.


Regards,
Jason

--
gentoo-dev@g.o mailing list