| 1 |
On Sat, 06 Sep 2003 13:05:16 -0500 |
| 2 |
David Sankel <sankeld@×××××××××××××.net> wrote: |
| 3 |
|
| 4 |
> 1) etc-update changes for a more automated system update |
| 5 |
|
| 6 |
Try dispatch-conf (from recent portage versions). It does unmodified |
| 7 |
files auto-upgrade, plus some other goodies. |
| 8 |
|
| 9 |
> 2) make.conf updates to be more automated |
| 10 |
|
| 11 |
Why something special for this one? With dispatch-conf, you already have |
| 12 |
automation for cvs headers. For the rest of the file, it's ok to do it |
| 13 |
manually. If you've only changed USE and CFLAGS, then the merge should |
| 14 |
really be straightforward (2 press on "l", the others on "r"), and it |
| 15 |
has the advantage to show you what's new in portage (new features, etc.) |
| 16 |
|
| 17 |
> 3) emerge -u world "NOTICE:" output changes. |
| 18 |
|
| 19 |
I use a small script that parse emerge log files for that, but it's true |
| 20 |
that a report at this end of an emerge would be nice. |
| 21 |
|
| 22 |
> 4) emerge -u world progress bar option |
| 23 |
> |
| 24 |
> the output of the "emerge -u world" command would probably have to be |
| 25 |
> standardized with some flags to mark the beginning and end of a |
| 26 |
> compile. |
| 27 |
|
| 28 |
I would imagine one progress bar for the overall process, and one for |
| 29 |
the current compilation. There is already some work that have been done |
| 30 |
here for a "make" progress meter: |
| 31 |
http://forums.gentoo.org/viewtopic.php?t=42346 |
| 32 |
But it was still buggy last time I checked. |
| 33 |
|
| 34 |
> 5) A simple graphical front end to maintenance commands such as |
| 35 |
> "emerge sync", "emerge -u world", and "etc-update". |
| 36 |
|
| 37 |
I think there are already frontends for emerge (one for gnome and one |
| 38 |
for kde if I remember well) that exist. Seen that somewhere on the forum |
| 39 |
I guess. |
| 40 |
|
| 41 |
> 6) A streamlined GUI install. |
| 42 |
|
| 43 |
http://glis.sourceforge.net/ |
| 44 |
|
| 45 |
> 7) Emerge -S and Emerge -s speed improvements. |
| 46 |
> |
| 47 |
> I don't know why these commands perform as slow as they do. My |
| 48 |
> intuition says that they could be an order of magnitude faster. |
| 49 |
> Perhaps a reimplementation in C/C++ or a data format change could |
| 50 |
> help. |
| 51 |
|
| 52 |
Caching the info from thousand files into a single one is enough. |
| 53 |
There are 2 approach: portage patch or separate tool: |
| 54 |
http://gentoo.devel-net.org/download/emerge-fastsearch.patch |
| 55 |
http://bugs.gentoo.org/show_bug.cgi?id=24756 |
| 56 |
|
| 57 |
-- |
| 58 |
TGL. |
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-dev@g.o mailing list |
Archives