[gentoo-dev] Re: Some suggestions

[David Sankel]

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@g.o mailing list