From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9336 invoked by uid 1002); 6 Sep 2003 23:54:53 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 21245 invoked from network); 6 Sep 2003 23:54:52 -0000 X-WM-Posted-At: mailandnews.com; Sat, 6 Sep 03 19:54:52 -0400 From: Jason Stubbs To: gentoo-dev@gentoo.org Date: Sun, 7 Sep 2003 08:53:25 +0900 User-Agent: KMail/1.5.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309070853.26402.jasonbstubbs@mailandnews.com> Subject: Re: [gentoo-dev] Some suggestions (SUMMARY?) X-Archives-Salt: 1c2c1e06-0671-45a3-bc46-7ad23c64f0e2 X-Archives-Hash: 2a08bed7f3629decd8481542156b4f41 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@gentoo.org mailing list