From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16150 invoked by uid 1002); 7 Sep 2003 00:05:12 -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 24607 invoked from network); 7 Sep 2003 00:05:11 -0000 From: Luke-Jr Organization: Gentoo Linux To: camio@yahoo.com, David Sankel , gentoo-dev@gentoo.org Date: Sun, 7 Sep 2003 00:04:57 +0000 User-Agent: KMail/1.5.3 References: In-Reply-To: GPG-Public-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD53E9583 MIME-Version: 1.0 Content-Type: Text/Plain; charset="shift_jis" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200309070005.07345.luke-jr@gentoo.org> Subject: Re: [gentoo-dev] Some suggestions X-Archives-Salt: de3ab733-52a6-410a-a18c-e5db4b3cc318 X-Archives-Hash: 5bf95a9fd665d8eb83eed9cd832c9e47 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 06 September 2003 06:05 pm, 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 agree. etc-update should, at very least, check modify dates on files and = if=20 they haven't been changed, simply replace them... > > 2) make.conf updates to be more automated > > Most gentoo users, I believe, modify this file. This specific file chang= es > quite often with updates. Since most users only modify the "USE" and > "CFLAGS" components, having an update that is automatic is plausible. Th= is > feature is a trade off between the integrity and consistency of the system > verses end-user maintenance time. It might be a good idea to setup some kind of system where etc-update can b= e=20 told *how* to update certain files. Maybe something like=20 "/etc/.__update_make.conf" could be run as a script... > > 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. I believe something like this is already being setup to some extent. Likely= it=20 will simply be sent to a new stream or something so it can be easilly logge= d=20 and displayed later. > > 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. I believe the -v option provides stuff scripts can look for... > > 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. I'm not sure, but wouldn't KPortage have something like this? > > 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. Gentoo is currently at 1.4. 1.0 was quite a while ago. I am working on a GU= I=20 install for computer newbies, and I believe the GLIS project is working on = a=20 GUI for more experienced users... > > 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. I doubt the language would improve the speed at all. I'm not sure why it's= =20 slow, but it could very well be I/O access... grepping the Portage tree isn= 't=20 any faster. =2D --=20 Luke-Jr Developer, Gentoo Linux http://www.gentoo.org/ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/WnYtZl/BHdU+lYMRAhKLAJ9b7SRMKCfy5qfH5myFkmaBKWarrgCfXFaq 546MXDUZCIIhu7D5A2EFo9o=3D =3DZNeH =2D----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list