Re: [gentoo-dev] Vanilla behaviour in Gentoo Linux (long email)

[Brad House <brad@mcve.com>]

Commenting below:


 >>
 >> --------------------------------
 >> Scenario 1: slocate and updatedb
 >> --------------------------------
 >>
 >> 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
 >> -f.


I do not agree with removing this stuff.  I think it should be default.
This is basic stuff that I've seen every other distro do as well, and
I would consider this to be standardized.  Though maybe what I would
recommend doing is adding documentation in the install guide that
will allow you to prevent this from being added to the cron, or
removing from the cron.  For those people who obviously don't know
how to remove a cron job without complaining.


 >>
 >> -------------------------------------
 >> Scenario 2: baselayout and /etc/issue
 >> -------------------------------------
 >> 1) Eliminate /etc/issue and rename it if it must be added to the system
 >>


no comment on this. This just doesn't bother me either way.
Whatever.


 >> ---------------------------------------------------
 >> Scenario 3: vanilla kernels and development sources
 >> ---------------------------------------------------
 >>
 >> 1) Provide the kernel in vanilla fashion without customisations
 >> 2) Reconsider using the alsa and vanilla use flags here as they violates
 >> the  rule of using use flags only for compile time switches.


Ok, this I can comment on.
development-sources has gone back to vanilla. The patches that were
previously applied were only _stable_ driver patches.  No controversial
patches. Just to prove my point, only 1 out of the 6 patches _did not_
make it into 2.6.0-test9-bk7, and that was a large realtek 8169 driver
patch.

As for gentoo-dev-sources that is brand new which is meant to be a
gentoo-patched version of the sources.  This should _never_ get as
bad as gentoo-sources though.  I hope only stable multiplatform patches
ever get added to this, otherwise stuff like amd64 will have to create
another kernel.  Johnm has assured me that it will only be a stable
patch branch, mainly driver updates, not necessarily feature enhancements.

The reason development-sources got patched in the first place was
because amd64 requires 2.6 kernels, and the 2.6.0 vanilla sources
would not compile on amd64, or had broken hardware drivers.  So it
was patched.  gentoo-dev-sources has taken over this responsibility
so as I said, it has gone back to vanilla.


 >>
 >> -------------------------------------
 >> scenario 4: kernel sources on portage
 >> -------------------------------------
 >> 1) Create gentoo patchsets only for finished releases and separate into
 >> different sources
 >> 2) Provide vanilla kernels as unaltered, unpatched and uncustomised
 >> sources  just as they would be if done manually
 >> 3) Agree on prerequisites that must be fulfilled prior to adding new
 >> kernels-sources or in fact any new packages onto portage.


I'm not sure what you consider a finished release.  Is it not proper
to patch a development release so it compiles on a platform?  Otherwise
what good is it.  The general community probably doesn't have the
know-how to patch it themselves to get it to compile/work.

And I agree, there are too many source packages, and I think the
reason for this is gentoo-sources having like 100 patches applied
to it that are x86 only, and do not work on other platforms, so
every other platform creates their own kernel tree, etc.

The rest is covered in #3.


 >>
 >> -------------------------
 >> Scenario 5: Ebuild speech
 >> -------------------------
 >> 1) Eliminate all use of sleep in ebuilds


obsurd. If you don't sleep after outputting messages, then
it auto-unmerges an older package, or continues onto another
packages, users will never see the usually important messages
output to the screen.

Also, your argument about gentoo claiming it gains 10s load-time, but
having to wait 15s more for compile time is probably the most
unintelligent argument I have ever heard.  What the hell does
compile time have to do with run time ...
sorry, but at that point I totally lost respect for this
message.


 >> 2) Eliminate all use of beeps via echo -ne "\a"


If it really really really bothers you, unplug your pc speaker.
Though I do not see a need for the bell either.


 >> 3) Write eclasses or modifications to portage which control logging and
 >> display - I have even written a bash wrapper (unfinished) around emerge
 >> which does log all output and displays all messages at end of every
 >> emerge  separated according to package names.


I agree there should be logging, but buffering?  that I don't
agree with.  To output stuff at the end can take an extremely long
time on a build like X or gcc.  Unlesss I'm misunderstanding, that's
ridiculous.


 >> 4) If there absolutely has to be sound it must be done through
 >> FEATURES="sound".  FEATURES="notify" can be used for message waits 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


ok... part of this is just, but please don't complain about EULAs.
Complaining about free software, yes companies put stipulations on
stuff they give away for free.  In capitalist societies, people need
justification for the work they do (compensation), etc. Don't complain
if you have a free license to use it... Unless you're a programmer, you
do not know what it's like to spend thousands of hours on something, then
people complain about spending money on it.

brad_mssw@gentoo.org




--
gentoo-dev@gentoo.org mailing list