On Saturday 01 May 2004 19:46, Jerry McBride wrote:
> Move all documentation to html and place it into a directory that apache
> can disseminate from. Having a central, online, browseable doc tree would
> be beautiful. Priceless...

All package documentation is accessible from http://localhost/doc/ in the 
default apache configuration files.

> Move away from the filesystem database that portage currently uses to
> something with a bit more perfomance... mysql, sqlite even postgres... An
> SQL backend interface would be WONDERFUL.

The biggest problem is that the ebuilds can only be parsed using bash. If that 
restriction can be lifted (by restricting / changing the ebuild format) 
parsing should go a lot faster. Really the installed package database is not 
the problem.

> Port portage to c or c++. Python sucks in the performance department... If
> not port to c then atleast start using psyco for a small perf boost...
> Rebuilding the cache (reading files) after a sync is... terrible... What a
> kludge...

Ever heard of the 10/90 rule. Really python is not the problem, the cache 
rebuilding is again ebuild parsing.

>
> Work on eliminating the constant caching of dependencies and other caching
> processes during boot up... On some of my boxes, these caching periods take
> longer than it does for KDE to boot to a usable desktop... What a drag on a
> laptop that I use to display linux with.... It's the first thing that
> windows advocates point and laugh at... Give me a break and cache the damn
> things when changes are MADE, not everytime you boot the box...

Probably those calculations should be rethought and a better algorithm should 
be devised. Calculating at boot time does make sense though as we have no way 
to know when the calculations are invalid.

> Tone down the amount of noise that emerge prints to the screen when using
> it. I don't need or want to see maybe 99.99% of all the stuff it prints
> during it operations. All you need is... either "THERE WAS AN ERROR" or
> "THERE WERE NO ERRORS". That in and of itself would boost performance a
> lot!... Less console updates, more cpu for the task at hand... Less user
> confusion...
>
> PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
> BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS BARS...PROGRESS
> BARS...PROGRESS BARS...
>
> Got the point??? :')

I see what you mean. There are two problems. It is very hard to make a 
progress bar as using useflags means that we cannot give a good idea of the 
amount of code to be compiled in total. Even measuring what has allready been 
done is hard. Also removing the build output creates much problems for 
bug-hunting.

If you don't want to see the compilation happen. Use "emerge foo &>/dev/null&" 
and you will see nothing. When bash has finished it will tell you whether it 
was successfull. (Instead you could direct to a file that you can check upon 
once in a while)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net