From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8186 invoked by uid 1002); 6 Sep 2003 19:52:09 -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 30267 invoked from network); 6 Sep 2003 19:52:09 -0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@gentoo.org From: David Sankel Date: Sat, 06 Sep 2003 14:45:20 -0500 Organization: Electron Consulting Message-ID: References: <200309062021.26817.puggy@bobspants.com> Reply-To: camio@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org User-Agent: Pan/0.14.0 (I'm Being Nibbled to Death by Cats!) Sender: news Subject: [gentoo-dev] Re: Some suggestions X-Archives-Salt: 5c012156-69af-4725-b355-50d02ee10a12 X-Archives-Hash: 78b53ef77b7fd047f06d64fb8a594e8e On Sat, 06 Sep 2003 20:21:20 +0100, Douglas Russell wrote: Hello Douglas. Thanks for your informed responses. >> 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". > > You can't be serious!? If you don't examine those etc-update changes you could > seriously screw up your system. I was afraid that it wouldn't be clear what I meant by this. I am not suggesting that all files could be automatically overwritten, only files that were not modified from the default by the user. For example the file: /etc/X11/chooser.sh was never changed by a given user on a given system. It is the default for the version they have. When a revision to the default is discovered, the system will flag that file as being one that the user hasn't specialized. In etc-update, there could be an option to update all flagged files automatically. Does that make more sense? >> 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. > > What about those of use with a load of other stuff in there. I just use the > interactive merge function of etc-update. Takes about 30 seconds to do > make.conf. I certainly would not suggest that the flexibility of the current system be undermined by such a feature. There should be an option for users such as yourself to use the system as is. >> 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. > > A progress bar would be difficult as its difficult to estimate how much code > is left to compile and/or how long that is going to take. It would probably > end up just saying 20 our of 24, 21 out of 24 etc. I personally prefer to see > the compilation so when it breaks I can see exactly where it was before it > broke. You are absolutely correct. Having something simple like 20/24 (currently working on package XXX) is probably the best such a progress bar could do. If the compilation does break, and that has been very rare in my experience, the program could output the log of that failed compile for inspection. I think this feature, being only an option, would be an enhancement that wouldn't remove any features you are interested in. > What places? Not modifying the CFLAGS? What do you suggest they should be left > at. I can assure you, your Athlon XP 2800+ or whatever will comparitivly > crawl with mcpu=i686. I suggest they be left at whatever the non-source based distributions leave them at. Perhaps I am misinformed about how much improvement one gets with aggressive optimization flags. Could you point me somewhere in the right direction? David J. Sankel -- gentoo-dev@gentoo.org mailing list