Dhruba Bandopadhyay <[EMAIL PROTECTED]> writes:
> Hello
>
[...]
> 1) Remove slocate from base system
> 2) Remove makewhatis from daily cron duties
> 3) Remove updatedb from daily cron duties
>
> I'm probably not alone in the fact that I never use slocate and given
> fixed location of package files and other files in gentoo finding
> things is easier than other distros especially given qpkg -l and etcat
I agree with this. In fact if I'm not mistaken, it was once the case
that you had to edit makewhatis and updatedb in /etc/cron.daily to
enable them. Who's dictating that daily execution of those is a good
idea anyway? IMO, /etc should be treated as user-territory as much
as possible. We don't start services in /etc/init.d/ for the user
automatically, so why should we be starting cron stuff?
[...]
> developer preference deviating from vanilla behaviour? There have
> been bugs filed about the removal of graphical /etc/issue which was
> later removed. Why not give the user the choice and put control in
> his or her hands? Customisation is a preference. My requests:
I'm just glad the gory ASCII art one is gone :-D
[...]
> On completion of merging the portage ebuild sleeps for ~15 seconds,
> the baselayout ebuild for ~10 seconds and even dev-sources sleeps for
> ~5 seconds whilst all these packages display messages. In my opinion,
> this is downright pointless. On a source distribution like this one
I agree with this. Delays and beeps are pointless. I'm probably
asleep in bed when these important messages, complete with delays and
beeps fly up the screen.
I think there's plenty of room for improvement in how we (developers)
communicate ebuild messages to the user. It's completely
unacceptable to throw some transient message up which is basically
gone in a screen-full of subsequent output. These messages need to
be logged somewhere as decent looking reports.
Currently there's a logging option in make.conf which captures ALL
ebuild output. We can hardly pass that off as a solution for users.
In Debian, such messages are sent by mail to root (and then to a real
user via the aliases db). This of course assumes that the user has a
running local mail delivery system which is not always the case.
Perhaps we can do better with a system that can use one of several
report mechanism (mail, to log file etc.). From an ebuild
perspective I'm thinking something like this:
cat <<EOF | ereport
Please note these new cool features in portage which require your
immediate attention
...
EOF
Which would render something nice and professional looking :-D like:
Package: sys-apps/portage-2.0.40-r1
Date: Mon Nov 3 09:55:31 2003
Please note these new cool features in portage which require your
immediate attention
...
Maybe this could be a GELP
[...]
> if absolutely necessary. It's a shame that finally EULA's have
> made ebuilds interactive and sound and message waits are further
> increasing merge time
Damn proprietary software!!!
Matt
--
Matthew Kennedy
Gentoo Linux Developer
--
[EMAIL PROTECTED] mailing list
