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

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

[Dhruba Bandopadhyay]

Hello

I'm writing about the enforcement of default/expected 'vanilla' behaviour of 
various attributes of the operating system.  These issues have been an 
annoyance for some time and are only being ventilated now that I have some 
time so please forgive me if I seem a little edgy.  My intention is to make 
suggestions and reach discussed optimal solutions.  When reading bear in 
mind the philosophy of putting control into the user's hand and providing 
choice to the user.

--------------------------------
Scenario 1: slocate and updatedb
--------------------------------
Out of the blue my hard drive starts roaring flat out.  This happens 
generally after the first reboot after installation or every day on a 
working system.  Given that this happens without any prior warning or any 
explicit consent or instruction during any part of install or configuration 
it can become extremely unpleasant especially if doing something rather 
important and resource intensive.  The culprit here is slocate and the 
makewhatis and updatedb cron scripts added to the daily cron duties!  One of 
the reasons I use Linux is because it only does things when I tell it to. 
Problems like this one sadly resemble Windows which when idle begins to 
grind away at hidden activities.  updatedb also requires root access to kill 
which can be an added hassle.  My requests:

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.

-------------------------------------
Scenario 2: baselayout and /etc/issue
-------------------------------------
With every emerge or update of baselayout or invocation of emerge -e a file 
called /etc/issue is placed on my system.  It serves no purpose other than 
to tell me what I already know such as what kernel, architecture and machine 
name I am using.  And on server machines with no monitor it does not even do 
that much.  Every time I have to delete this file and it gets added back in 
later.  Is this an example of 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:

1) Eliminate /etc/issue and rename it if it must be added to the system

---------------------------------------------------
Scenario 3: vanilla kernels and development sources
---------------------------------------------------
Usually, I get the latest bk snapshot from kernel.org, unpack and compile 
manually.  However, recently, on a new install I emerged development-sources 
to fulfill virtual/linux-sources and was later puzzled to find its contents 
in /usr/src/linux/linux-2.6.x-test-y-patchset-a.b and many other involuntary 
steps being taken by the ebuild.  This confounded many users and bugs were 
filed about install locations, alsa actions and also about adding gentoo 
patchsets to dev-sources.  On forums, I heard something about a 'vanilla' 
use flag to prevent the gentoo patchset although now I only see it in IUSE 
and not in emerge -vp oddly.  Why can't it be as simple as download > unpack 
 > merge rather than download > unpack > play with permissions > run 
genpatches to patch sources > merge into different location?  What is the 
2.6-test gentoo patchset and why is it necessary and applied by default on 
an unfinished release?  My requests:

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.

-------------------------------------
scenario 4: kernel sources on portage
-------------------------------------
$ emerg -qs sources
<snip>
$ emerge -qs sources | grep -c '^*'
38

Currently, there are 38 kernel sources on portage.  A few weeks back there 
were 36.  Then gentoo-test-sources was added as a branch to gentoo-sources 
and also recently gentoo-dev-sources has been added as a branch to 
development-sources.  Now, does this only strike me as being a very large 
number resulting from liberal means?  Are there any rules that govern 
creating new kernel sources and justifying their need?  Providing choice is 
good but having this many kernel sources not only confuses the user and 
makes him indecisive but it also makes dev maintenance and administration 
more difficult.  Also, problems such as the description for 
gentoo-dev-sources being exactly the same as development-sources will only 
serve to increase confusion.  Is it necessary to provide gentoo patchsets 
for every possible kernel variant?  Even if you go by the rule that stable 
kernels will have patchsets the current dev-sources violates it.  My requests:

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.

-------------------------
Scenario 5: Ebuild speech
-------------------------
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 especially 
where claims about speed are made not only of portage but also the packages 
themselves what is the point in gaining ~10 seconds load time when you lose 
~15 seconds compile time?  What is the net gain?  To make matters worse, 
ebuilds beep out loud through pc speaker on important sys-apps merges whilst 
sleeping in between which can make one very uncomfortable in office or quiet 
environments.  I understand it is important to get messages to the user but 
this is not the way.  There should be other means whereby all messages are 
accumulated and logged and displayed at the end of all merges (bugs are 
open).  I currently this as follows.

$ emerge -Du world | tee updates.log
$ grep '01m' updates.log  ( <-- this gives all messages in log file without 
use of sleep)

My requests:

1) Eliminate all use of sleep in ebuilds
2) Eliminate all use of beeps via echo -ne "\a"
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.
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

Overall, I would say vanilla behaviour should always be exhibited by default 
in all aspects of the operating system in favour of user preference or dev 
preference.  Focus should be on instructing the user on how to make a change 
rather than making the change and expecting the user to reverse it. 
Exceptions are where the change is vanilla in itself like providing stock 
kernel configs to newbie users as genkernel does.

Please discuss as you wish.  I would be grateful if these issues were paid 
some attention and I look forward to receiving feedback whether you share 
the same experience or have opposing views.  If any of them should be filed 
as bugs

with sincere regards
Dhruba Bandopadhyay

--
gentoo-dev@gentoo.org mailing list

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

[Brad House]

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

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

[Jon Portnoy]

On Mon, Nov 03, 2003 at 01:29:19AM +0000, Dhruba Bandopadhyay wrote:
> Hello
> 
> I'm writing about the enforcement of default/expected 'vanilla' behaviour 
> of various attributes of the operating system.  These issues have been an 
> annoyance for some time and are only being ventilated now that I have some 
> time so please forgive me if I seem a little edgy.  My intention is to make 
> suggestions and reach discussed optimal solutions.  When reading bear in 
> mind the philosophy of putting control into the user's hand and providing 
> choice to the user.
> 
> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------

Many, many users use locate and many would complain if it was missing. 
Every distribution I've used considers slocate to be part of a pretty 
basic install and places it in the daily cron jobs. If you don't want it 
there, rm /etc/cron.daily/locatedb.cron and you're all set.

> 
> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
> With every emerge or update of baselayout or invocation of emerge -e a file 
> called /etc/issue is placed on my system.  It serves no purpose other than 
> to tell me what I already know such as what kernel, architecture and 
> machine name I am using.  And on server machines with no monitor it does 
> not even do that much.  Every time I have to delete this file and it gets 
> added back in later.  Is this an example of 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:

This is an example of expected behavior not necessarily fitting what 
you, personally, expect. I'm sorry, we can't cater to everyone: if it's 
there, some people go "I don't want it," if it's not there, some people 
go "I want it" -- I, frankly, think it should stay. It's not harming 
anything, unless that 4k (unless you use a different blocksize) is 
really killing you.

> 
> 1) Eliminate /etc/issue and rename it if it must be added to the system
> 
> ---------------------------------------------------
> Scenario 3: vanilla kernels and development sources
> ---------------------------------------------------
> Usually, I get the latest bk snapshot from kernel.org, unpack and compile 
> manually.  However, recently, on a new install I emerged 
> development-sources to fulfill virtual/linux-sources and was later puzzled 
> to find its contents in /usr/src/linux/linux-2.6.x-test-y-patchset-a.b and 
> many other involuntary steps being taken by the ebuild.  This confounded 

Already removed and moved to gentoo-dev-sources or something like that.

> Currently, there are 38 kernel sources on portage.  A few weeks back there 
> were 36.  Then gentoo-test-sources was added as a branch to gentoo-sources 
> and also recently gentoo-dev-sources has been added as a branch to 
> development-sources.  Now, does this only strike me as being a very large 
> number resulting from liberal means?  Are there any rules that govern 
> creating new kernel sources and justifying their need?  Providing choice is 

Yes. And the install guide specifically recommends gentoo-sources or 
vanilla-sources. Who's confused?

> 
> 1) Create gentoo patchsets only for finished releases and separate into 
> different sources

Unfortunately we have situations where we need driver patches for 2.6, 
for example. This is why there's a gentoo-dev-sources. There are other 
similar situations.

> 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.

Wait, wait, wait - I thought you were upset because we weren't letting 
users make choices? Now you're upset because we're offering too many 
choices?

> 
> -------------------------
> Scenario 5: Ebuild speech
> -------------------------
> 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 especially 

Except that it sleeps for _very important messages_. Those timers are 
there because people were totally missing those messages.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

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

[Chris Smith]

On Monday 03 November 2003 14:29, Dhruba Bandopadhyay wrote:
> Hello
>
> I'm writing about the enforcement of default/expected 'vanilla' behaviour
> of various attributes of the operating system.  These issues have been an
> annoyance for some time and are only being ventilated now that I have some
> time so please forgive me if I seem a little edgy.  My intention is to make
> suggestions and reach discussed optimal solutions.  When reading bear in
> mind the philosophy of putting control into the user's hand and providing
> choice to the user.

Ok, my reply isn't quite as long, but I attempt to address all the issues that 
you bring up. My views expressed here are IN NO WAY anything to do with the 
views of Gentoo Linux, as I am just a user. My replies are based on what 
Gentoo Linux means to me.

> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------
> Out of the blue my hard drive starts roaring flat out.  This happens
> generally after the first reboot after installation or every day on a
> working system.  Given that this happens without any prior warning or any
> explicit consent or instruction during any part of install or configuration
> it can become extremely unpleasant especially if doing something rather
> important and resource intensive.  The culprit here is slocate and the
> makewhatis and updatedb cron scripts added to the daily cron duties!  One
> of the reasons I use Linux is because it only does things when I tell it
> to. Problems like this one sadly resemble Windows which when idle begins to
> grind away at hidden activities.  updatedb also requires root access to
> kill which can be an added hassle.  My requests:
>
> 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.

slocate, updatedb and makewhatis are standard UNIX commands/programs. It's 
basically "compatability" so that a user from redhat can log into a Gentoo 
server and still find his way around. In my opinion, the user shouldnt have 
to edit any configuration file to have a functional Linux system, which is 
reasonably compatable with almost any other distro.

Instead, for you to get the system the way you want it, you must edit the 
configuration files. If you don't use slocate, there is nothing at all 
stopping you from editing the cron.daily file and removing its entry. This 
way, another distro user can come in and use most of the commands he's used 
to. Now the thing is, the control IS in the hands of the user, you can change 
your system anyway you want, but I argue that Gentoo should retain standard 
UNIX utils. Even Debian provides this functionality by default.

> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
> With every emerge or update of baselayout or invocation of emerge -e a file
> called /etc/issue is placed on my system.  It serves no purpose other than
> to tell me what I already know such as what kernel, architecture and
> machine name I am using.  And on server machines with no monitor it does
> not even do that much.  Every time I have to delete this file and it gets
> added back in later.  Is this an example of 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:
>
> 1) Eliminate /etc/issue and rename it if it must be added to the system

Again, why should the entire distro use (or not use) something that you don't 
want.

chris@chris chris $ ls -alo /etc/ | grep issue
-rw-r--r--    1 root           30 Sep 25 09:46 issue

are you really missing those 30 bytes? Does the system information at login 
really rub you up the wrong way?

If its that much of a problem, just: ln -s /dev/null /etc/issue

Also, I think now you are arguing that vanilla behaviour should be followed, 
but in the previous scenario you were arguing that we should deviate from 
standard Linux procedures.

> ---------------------------------------------------
> Scenario 3: vanilla kernels and development sources
> ---------------------------------------------------
> Usually, I get the latest bk snapshot from kernel.org, unpack and compile
> manually.  However, recently, on a new install I emerged
> development-sources to fulfill virtual/linux-sources and was later puzzled
> to find its contents in /usr/src/linux/linux-2.6.x-test-y-patchset-a.b and
> many other involuntary steps being taken by the ebuild.  This confounded
> many users and bugs were filed about install locations, alsa actions and
> also about adding gentoo patchsets to dev-sources.  On forums, I heard
> something about a 'vanilla' use flag to prevent the gentoo patchset
> although now I only see it in IUSE and not in emerge -vp oddly.  Why can't
> it be as simple as download > unpack
>
>  > merge rather than download > unpack > play with permissions > run
>
> genpatches to patch sources > merge into different location?  What is the
> 2.6-test gentoo patchset and why is it necessary and applied by default on
> an unfinished release?  My requests:
>
> 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.

I really don't know what's going on here. But I'm absolutely sure thats what 
the vanilla-sources package is there for. If you want a vanilla test kernel, 
development-sources. 

I personally don't see a problem here, as number 1 in your request is already 
in place. Lots of kernel packages == lots of choice.

Also, I thought use flags were to enable features in packages. Where does it 
say it's compile time only? Perhaps it should be changed to a more general 
definition, as I think the use flags are the best way to handle things.

> -------------------------------------
> scenario 4: kernel sources on portage
> -------------------------------------
> $ emerg -qs sources
> <snip>
> $ emerge -qs sources | grep -c '^*'
> 38
>
> Currently, there are 38 kernel sources on portage.  A few weeks back there
> were 36.  Then gentoo-test-sources was added as a branch to gentoo-sources
> and also recently gentoo-dev-sources has been added as a branch to
> development-sources.  Now, does this only strike me as being a very large
> number resulting from liberal means?  Are there any rules that govern
> creating new kernel sources and justifying their need?  Providing choice is
> good but having this many kernel sources not only confuses the user and
> makes him indecisive but it also makes dev maintenance and administration
> more difficult.  Also, problems such as the description for
> gentoo-dev-sources being exactly the same as development-sources will only
> serve to increase confusion.  Is it necessary to provide gentoo patchsets
> for every possible kernel variant?  Even if you go by the rule that stable
> kernels will have patchsets the current dev-sources violates it.  My
> requests:
>
> 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.

1) Why? A lot of Gentoo users (probably more so than any other distro) use 
development kernels, and the Gentoo patchset provides a lot of functionality. 
Have a look at the popularity of "love-sources" on the forums.
2) As far as I know, they are. I use a variety of kernels and when I use the 
"vanilla-sources", thats exactly what I get, vanilla kernel sources.
3) Care to elaborate on this some more? There is a variety of criteria that 
has to be complete before ebuilds are added to portage. Please elaborate on 
this point.

I like the amount of kernel choice we have available, and contrary to your 
argument, I don't think it's confusing at all to the user. As long as the 
kernel guide on the Gentoo website is kept up to date, I don't see a problem 
here.

> -------------------------
> Scenario 5: Ebuild speech
> -------------------------
> 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 especially
> where claims about speed are made not only of portage but also the packages
> themselves what is the point in gaining ~10 seconds load time when you lose
> ~15 seconds compile time?  What is the net gain?

Are you telling me you install software more times than you load it? This 
argument is very weak. I agree that ebuilds beeping at me when I'm trying to 
update world gets on my wick a bit, but until another method for relaying 
important (and they are important) messages to the user, I guess it has to 
stay.

>  To make matters worse,
> ebuilds beep out loud through pc speaker on important sys-apps merges
> whilst sleeping in between which can make one very uncomfortable in office
> or quiet environments.  I understand it is important to get messages to the
> user but this is not the way.  There should be other means whereby all
> messages are accumulated and logged and displayed at the end of all merges
> (bugs are open).  I currently this as follows.

Adressed this above.

> My requests:
>
> 1) Eliminate all use of sleep in ebuilds

Agreed. Although it's mildly annoying, I don't think it's a huge priority.

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

Agreed. Emerge is meant to be non-interactive, and if you leave the PC while 
you're updating world you will miss valuable message. The install shouldn't 
have to be monitored.

> 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.

Great, file a bug, attach the code and lets see about getting this into 
portage 2.1!

> 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
>
> Overall, I would say vanilla behaviour should always be exhibited by
> default in all aspects of the operating system in favour of user preference
> or dev preference.  Focus should be on instructing the user on how to make
> a change rather than making the change and expecting the user to reverse
> it. Exceptions are where the change is vanilla in itself like providing
> stock kernel configs to newbie users as genkernel does.

On the other hand, as Gentoo is a distrobution for some of the more advanced 
linux goats, I think defaults should be set, and if you don't like it you can 
customise it. Gentoo has many users and can't please all of them.

> with sincere regards
> Dhruba Bandopadhyay

Cheers,
Chris.

-- 
            It is easier to fix Unix than to live with NT.


--
gentoo-dev@gentoo.org mailing list

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

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1329 bytes --]

 Is it me, or does it seem like when there are less than popular suggestions, 
there are often more nasty replies or flame-tinted repsonses from the 
developers, or am I just overly sensitive?
 I would also like to add some bait to this:
I dont care about the slocate thing myself, I rarely use it, but a renicing 
has a great effect on performance.Would like to have messages logged 
somewhere, as I sleep through updates, consequently, never knew it was 
beeping?:) Agree on the kernel thing, but it got remedied, for the most part.
The /etc/issue thing- we didn't have it for a long ass time, somebody made 
some neat gentoo artwork, and it became standard.Whoopee. A quick fix for 
that I had was to "echo ^[[2J^[[f > /etc/issue" from local.start and not only 
does it keep anything from being displayed, it makes sure the screen is 
blanked after logout.
 I like being Unix compatible, but not so to the point of we must include 
everything I might ever see on a Unix anywhere. Simply providing access to 
install the packages that I might expect to find on a Unix box is enough. 
Also noted somebody said "Debian provides..." yeesh, lets not take our distro 
cues from there please.
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jon Portnoy]

On Sun, Nov 02, 2003 at 07:33:10PM -0800, C. Brewer wrote:
Content-Description: signed data
>  Is it me, or does it seem like when there are less than popular suggestions, 
> there are often more nasty replies or flame-tinted repsonses from the 
> developers, or am I just overly sensitive?

I can put a "Opinions are my own and not those of Gentoo Linux or any 
other entity unless stated otherwise" disclaimer in my sig like I do on 
the forums if it's necessary.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

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

[Björn Lindström]

Dhruba Bandopadhyay <dhruba@codewordt.co.uk> writes:

> 1) Eliminate all use of sleep in ebuilds
> 2) Eliminate all use of beeps via echo -ne "\a"
> 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.
> 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

I would like to add

5) Eliminate escape strings that affect xterm titles from emerge.

I now find myself doing

$ TERM=vt100 emerge ...

-- 
Björn Lindström <bkhl@elektrubadur.se>
http://bkhl.elektrubadur.se/


--
gentoo-dev@gentoo.org mailing list

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

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1166 bytes --]

On Sunday 02 November 2003 7:45, Jon Portnoy wrote:
> On Sun, Nov 02, 2003 at 07:33:10PM -0800, C. Brewer wrote:
> Content-Description: signed data
>
> >  Is it me, or does it seem like when there are less than popular
> > suggestions, there are often more nasty replies or flame-tinted repsonses
> > from the developers, or am I just overly sensitive?
>
> I can put a "Opinions are my own and not those of Gentoo Linux or any
> other entity unless stated otherwise" disclaimer in my sig like I do on
> the forums if it's necessary.

Being not the first time I've heard something along these lines, forgive me if 
I am slightly skeptical. Opinions are your own, regardless of if they 
coincide with Gentoo's. But as a person who is entitled to any opinion, nasty 
or otherwise, while yet still at least partly responsible for steering the 
distibution... where does the line get drawn? Do we take nasty responses as 
merely personal opinion until a required number of devs have a similar view 
on it, and then it's official?
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Spider]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

begin  quote
On Mon, 03 Nov 2003 06:55:09 +0100
bkhl@elektrubadur.se (Björn Lindström) wrote:



> 5) Eliminate escape strings that affect xterm titles from emerge.
> 
> I now find myself doing
> 
> $ TERM=vt100 emerge ...

$ grep xterm /etc/make.conf
#  'notitles'    disables xterm titlebar updates (which contain status
#  info). 


seems somone found them annoying before you did.


//Spider
-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Jon Portnoy]

On Sun, Nov 02, 2003 at 10:31:41PM -0800, C. Brewer wrote:
Content-Description: signed data
> On Sunday 02 November 2003 7:45, Jon Portnoy wrote:
> > On Sun, Nov 02, 2003 at 07:33:10PM -0800, C. Brewer wrote:
> > Content-Description: signed data
> >
> > >  Is it me, or does it seem like when there are less than popular
> > > suggestions, there are often more nasty replies or flame-tinted repsonses
> > > from the developers, or am I just overly sensitive?
> >
> > I can put a "Opinions are my own and not those of Gentoo Linux or any
> > other entity unless stated otherwise" disclaimer in my sig like I do on
> > the forums if it's necessary.
> 
> Being not the first time I've heard something along these lines, forgive me if 
> I am slightly skeptical. Opinions are your own, regardless of if they 
> coincide with Gentoo's. But as a person who is entitled to any opinion, nasty 
> or otherwise, while yet still at least partly responsible for steering the 
> distibution... where does the line get drawn? Do we take nasty responses as 
> merely personal opinion until a required number of devs have a similar view 
> on it, and then it's official?

I'd like to think I'm frank about things rather than an asshole about 
things, in any case.
("But I thought you were Jon...")

In all seriousness, I haven't seen anyone say anything especially 
inflammatory.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

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

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1537 bytes --]

 I'd say I prefer frank responses to other, however I've been of the opinion 
that in the written sense, most people don't type as fast they think or 
speak. Therefore some of the things I've heard here in the past, while they 
may be considered candid or frank in a face-to-face situation, have a 
different light in a written sense, as I think some of us may subconciously 
believe that thought was put into what we write, and makes it take on a 
pointed feel. The point I was illustrating in the aspect of user/dev 
relations can be summed up in this slightly amusing anecdote-

 One Christmas vacation, about ten or so years ago, I was at a company holiday 
party, with a compatriot not employed by employer, where we immediately fell 
to consuming a fair amount of alcoholic beverages (read open bar). My 
employers daughter was a rather foul snooty individual with a unique way of 
phrasing thing in a particularly unladylike manner. She approached us and 
began to issue some orders on things she insisted be done immediately. My 
buddy, not working for her or her father, and myself, not on the clock, 
company property, or even on her residence, took offense at her tone and 
proceeded to tell her as much in a much ungentlemanly way. (I did say open 
bar). My opinions were my own at the time as well, yet I'll give ya a guess 
at who got the first pink-slip close to lay-off time:)  
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Sun, 2003-11-02 at 20:29, Dhruba Bandopadhyay wrote:
> 1) Eliminate all use of sleep in ebuilds
> 2) Eliminate all use of beeps via echo -ne "\a"
> 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.
> 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

The FEATURES="sound" and FEATURES="notify" make sense to me, assuming
they're set by default along with some sort of FEATURES="logmessages"
that would save messages for later.

I've been duly annoyed by beeps late at night while others are sleeping
as well.

Every ebuild with 'sleep' or beeps would need to be checked to make sure
any instance wasn't necessary.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Toby Dickenson]

On Monday 03 November 2003 02:16, Jon Portnoy wrote:

> > -------------------------
> > Scenario 5: Ebuild speech
> > -------------------------
> > 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
> > especially
>
> Except that it sleeps for _very important messages_. Those timers are
> there because people were totally missing those messages.

My understanding of the original posters dislike is not that beep-and-sleep 
happens, nor that it happens by default, but rather that the behaviour is 
hard coded into individual ebuilds in a way that makes it difficult to 
customise.

I think we can reasonably debate whether beep-and-sleep is the best way of 
getting the users attention for these important messages, but I would be 
suprised if we didnt all agree that the current approach of putting 
beep-and-sleep in individual ebuilds is substandard.

-- 
Toby Dickenson


--
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

>
> The FEATURES="sound" and FEATURES="notify" make sense to me, assuming
> they're set by default along with some sort of FEATURES="logmessages"
> that would save messages for later.
>
> I've been duly annoyed by beeps late at night while others are sleeping
> as well.
>
> Every ebuild with 'sleep' or beeps would need to be checked to make sure
> any instance wasn't necessary.
>

I agree with you. As a temporary solution to the beep problem you might
consider using "emerge bla &>/tmp/bla.log&", which aditionally gives you a
log so you can more easilly debug issues.

Paul

--
gentoo-dev@gentoo.org mailing list

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

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 7226 bytes --]

On Mon, Nov 03, 2003 at 01:29:19AM +0000, Dhruba Bandopadhyay wrote:
> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------
[snip]
> 1) Remove slocate from base system
> 2) Remove makewhatis from daily cron duties
> 3) Remove updatedb from daily cron duties

Items 2 and 3 above are easily accomplished with 
chmod -x /etc/cron.daily/{makewhatis.cron,slocate}
That's all that's needed.

> 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.
The big issue at hand isn't pleasing just you, but finding the best
common ground for all Gentoo users. Based on what I know of UNIX users,
I'd say more often than not they want and use the the locate command
(which is provided by slocate).

You note that you are interested in the enforcement of 'expected vanilla
behaviors' of the operating system.

Vanilla is defined as:
"Lacking adornments or special features; basic or ordinary"
(Dictionary.com)

> Overall, I would say vanilla behaviour should always be exhibited by 
> default in all aspects of the operating system in favour of user preference 
> or dev preference. 
I haven't seen a single UNIX other there (apart from LFS and it's kin)
where some form of regularly running updatedb/makewhatis isn't present
by default. 

Therefore, it logically follows that it is ordinary and vanilla to have
slocate and makewhatis in place.

I will concede one point with regard to them, running them as 'niced' as
possible is probably a worthwhile change to make so that they don't hit
our systems so hard.

Consider also tweaking what time the daily cronjobs etc. run, so that
they take place at a time your computer is up and running, but you
aren't actively using it.

> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
[snip]
Again, see my comments about what is vanilla.

> My requests:
> 1) Eliminate /etc/issue and rename it if it must be added to the system
Somewhere, I recall seeing a package that required /etc/issue to exist,
as it caused problems otherwise.

> ---------------------------------------------------
> Scenario 3: vanilla kernels and development sources
> ---------------------------------------------------
> -------------------------------------
> scenario 4: kernel sources on portage
> -------------------------------------
[snip]
I'm not going to argue about kernel stuff, other than to say that there
should be an absolute minimal amount of modification compared to how
each set of sources ship. Please note that is not only vanilla sources,
but rather all sources in the tree. 

> 1) Create gentoo patchsets only for finished releases and separate into 
> different sources
In the case of the custom gentoo kernels, they are shipping with plenty
of customizations of their own, because they intend to have them.

> 2) Provide vanilla kernels as unaltered, unpatched and uncustomised sources 
> just as they would be if done manually
Acceptable changes should be fixes of major breakages and compilation
fixes specific to the Gentoo system. GCC3.3 string fixes for a major example.

> 3) Agree on prerequisites that must be fulfilled prior to adding new 
> kernels-sources or in fact any new packages onto portage.
Define pre-requisites in this case. I'd say any commonly used and
expected kernel for all architectures that Gentoo supports and is in the
process of trying to support belong in the tree.

> -------------------------
> Scenario 5: Ebuild speech
> -------------------------
[snip]
The beeps and waiting are there for a specific reason, in that sometimes
there are very important messages that WILL break a users system unless
they do some additional instruction that is specified. We generally try
very hard to avoid this, but there are some cases where it cannot be
avoided. 

For an example, I'm currently writing up some ebuilds for the new 5.3
tree of vpopmail, because it will be released from it's upstream beta
state soon. The upgrade path involved in this, if I were to have a
script to do it automatically, would entail forcing the user to stop
courier-imap+qmail, run the emerge upgrade, run a command to migrate
their data, and recompile courier-imap, and restart qmail+courier-imap.
So now, how to go about this and NOT break the system of the user that
runs 'emerge -u world' and goes to bed? There is no simple solution for
this.

> Focus should be on instructing the user on how to make a change rather
> than making the change and expecting the user to reverse it. 
The big problem is quite simply that users don't read the big warnings
and information as it stands already. The beeps and sleeping at least
get a fair number of users to read the messages and find out what to do.
However I still get a significent number of bugs filed just because
users fail to read the instructions that have been provided.

One that keeps getting filed as a bug with some regularity is the mysql
configuration instructions to create the database and set the initial
passwords. Absolutely essential for the application to work, and
completely documented in the pkg_postinst of the package telling you to
run the ebuild ... config command. Yet I still get several bugs a month
for this, because users failed to read the instructions that we
provided.

If there were a solution that could resolve the issues you have with the
delays and waiting, while still getting more of the users to READ the
instructions that are already provided, I'd be incredibly grateful as it
would reduce the amount of time I spend on non-productive bugs. For each
of the bugs that gets filed presently like this, I try as hard as I can
to ensure that the user understands the problem and is explictly shown
how to resolve it.

> 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.
Logging is already done, see PORT_LOGDIR in make.conf. If you really
need to find the messages afterwards, just grep in the newly produced
logfiles as you do above.

> 1) Eliminate all use of sleep in ebuilds
> 2) Eliminate all use of beeps via echo -ne "\a"
> 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
No arguments with this in principle. Lets have FEATURES="sound" and
FEATURES="wait", both enabled by default.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

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

[Antonio Dolcetta]

On Mon, 3 Nov 2003 10:37:12 +0100 (CET)
"Paul de Vrieze" <pauldv@gentoo.org> wrote:

> I agree with you. As a temporary solution to the beep problem you might
> consider using "emerge bla &>/tmp/bla.log&", which aditionally gives you a
> log so you can more easilly debug issues.
> 

Even better, use script(1)

Ciao

	Antonio

--
gentoo-dev@gentoo.org mailing list

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

[purslow]

031103 Spider wrote:
> 03 Nov 2003 bkhl@elektrubadur.se (Björn Lindström) wrote:
>> 5) Eliminate escape strings that affect xterm titles from emerge.
>   $ grep xterm /etc/make.conf
>   # 'notitles' disables xterm titlebar updates (which contain status info). 
> seems somone found them annoying before you did.

i find the titlebar status report very reassuring:
  ... 6/97 ... 7/97 ... 8/97 ...  (smile).

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

--
gentoo-dev@gentoo.org mailing list

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

[Matthew Kennedy]

Dhruba Bandopadhyay <dhruba@codewordt.co.uk> writes:

> Hello
>
> I'm writing about the enforcement of default/expected 'vanilla'
> behaviour of various attributes of the operating system.  These issues
> have been an annoyance for some time and are only being ventilated now
> that I have some time so please forgive me if I seem a little edgy.
> My intention is to make suggestions and reach discussed optimal
> solutions.  When reading bear in mind the philosophy of putting
> control into the user's hand and providing choice to the user.
>
> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------
> Out of the blue my hard drive starts roaring flat out.  This happens
> generally after the first reboot after installation or every day on a
> working system.  Given that this happens without any prior warning or
> any explicit consent or instruction during any part of install or
> configuration it can become extremely unpleasant especially if doing
> something rather important and resource intensive.  The culprit here
> is slocate and the makewhatis and updatedb cron scripts added to the
> daily cron duties!  One of the reasons I use Linux is because it only
> does things when I tell it to. Problems like this one sadly resemble
> Windows which when idle begins to grind away at hidden activities.
> updatedb also requires root access to kill which can be an added
> hassle.  My requests:
>
> 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.
>
> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
> With every emerge or update of baselayout or invocation of emerge -e a
> file called /etc/issue is placed on my system.  It serves no purpose
> other than to tell me what I already know such as what kernel,
> architecture and machine name I am using.  And on server machines with
> no monitor it does not even do that much.  Every time I have to delete
> this file and it gets added back in later.  Is this an example of
> 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:
>
> 1) Eliminate /etc/issue and rename it if it must be added to the system
>
> ---------------------------------------------------
> Scenario 3: vanilla kernels and development sources
> ---------------------------------------------------
> Usually, I get the latest bk snapshot from kernel.org, unpack and
> compile manually.  However, recently, on a new install I emerged
> development-sources to fulfill virtual/linux-sources and was later
> puzzled to find its contents in
> /usr/src/linux/linux-2.6.x-test-y-patchset-a.b and many other
> involuntary steps being taken by the ebuild.  This confounded many
> users and bugs were filed about install locations, alsa actions and
> also about adding gentoo patchsets to dev-sources.  On forums, I heard
> something about a 'vanilla' use flag to prevent the gentoo patchset
> although now I only see it in IUSE and not in emerge -vp oddly.  Why
> can't it be as simple as download > unpack > merge rather than
> download > unpack > play with permissions > run genpatches to patch
> sources > merge into different location?  What is the 2.6-test gentoo
> patchset and why is it necessary and applied by default on an
> unfinished release?  My requests:
>
> 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.
>
> -------------------------------------
> scenario 4: kernel sources on portage
> -------------------------------------
> $ emerg -qs sources
> <snip>
> $ emerge -qs sources | grep -c '^*'
> 38
>
> Currently, there are 38 kernel sources on portage.  A few weeks back
> there were 36.  Then gentoo-test-sources was added as a branch to
> gentoo-sources and also recently gentoo-dev-sources has been added as
> a branch to development-sources.  Now, does this only strike me as
> being a very large number resulting from liberal means?  Are there any
> rules that govern creating new kernel sources and justifying their
> need?  Providing choice is good but having this many kernel sources
> not only confuses the user and makes him indecisive but it also makes
> dev maintenance and administration more difficult.  Also, problems
> such as the description for gentoo-dev-sources being exactly the same
> as development-sources will only serve to increase confusion.  Is it
> necessary to provide gentoo patchsets for every possible kernel
> variant?  Even if you go by the rule that stable kernels will have
> patchsets the current dev-sources violates it.  My requests:
>
> 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.
>
> -------------------------
> Scenario 5: Ebuild speech
> -------------------------
> 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
> especially where claims about speed are made not only of portage but
> also the packages themselves what is the point in gaining ~10 seconds
> load time when you lose ~15 seconds compile time?  What is the net
> gain?  To make matters worse, ebuilds beep out loud through pc speaker
> on important sys-apps merges whilst sleeping in between which can make
> one very uncomfortable in office or quiet environments.  I understand
> it is important to get messages to the user but this is not the way.
> There should be other means whereby all messages are accumulated and
> logged and displayed at the end of all merges (bugs are open).  I
> currently this as follows.
>
> $ emerge -Du world | tee updates.log
> $ grep '01m' updates.log  ( <-- this gives all messages in log file
> without use of sleep)
>
> My requests:
>
> 1) Eliminate all use of sleep in ebuilds
> 2) Eliminate all use of beeps via echo -ne "\a"
> 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.
> 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
>
> Overall, I would say vanilla behaviour should always be exhibited by
> default in all aspects of the operating system in favour of user
> preference or dev preference.  Focus should be on instructing the user
> on how to make a change rather than making the change and expecting
> the user to reverse it. Exceptions are where the change is vanilla in
> itself like providing stock kernel configs to newbie users as
> genkernel does.
>
> Please discuss as you wish.  I would be grateful if these issues were
> paid some attention and I look forward to receiving feedback whether
> you share the same experience or have opposing views.  If any of them
> should be filed as bugs
>
> with sincere regards
> Dhruba Bandopadhyay
>
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
Matthew Kennedy
Gentoo Linux Developer

--
gentoo-dev@gentoo.org mailing list

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

[Matthew Kennedy]

Dhruba Bandopadhyay <dhruba@codewordt.co.uk> 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

--
gentoo-dev@gentoo.org mailing list

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

[Luca Barbato]

I'll try to be as short as possible

Dhruba Bandopadhyay wrote:
> Hello

hi, everything following is just what I think, feel free to tell that 
I'm not gentle enough.


> 
> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------
> 

If you use cron you have some default cronjobs...
> 1) Remove slocate from base system
No, locate is useful and commonly provided as default on every other 
distro/os I used in the past
> 2) Remove makewhatis from daily cron duties
up to you
> 3) Remove updatedb from daily cron duties
up to you again
> 
> 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 think that you are quite alone, locate is QUITE useful if you have 
many files and many places in which they may stay. I'm not writing about 
system file as applications, I mean user files (as in work / study / 
whatever) . Ok, that is a matter of use of the system but overall I 
expect people to have more personal data than system data.

> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
> 
> 1) Eliminate /etc/issue and rename it if it must be added to the system
No, that is a common file and I'd expect people complaining about if got 
removed. The issue file and motd file are useful on a multi user system.
> 
> ---------------------------------------------------
> Scenario 3: vanilla kernels and development sources
> ---------------------------------------------------
> 1) Provide the kernel in vanilla fashion without customisations
already present
> 2) Reconsider using the alsa and vanilla use flags here as they violates 
> the rule of using use flags only for compile time switches.
could you explain more? I'd like to know more about that.
> 
> -------------------------------------
> scenario 4: kernel sources on portage
> -------------------------------------
> $ emerg -qs sources
> <snip>
> $ emerge -qs sources | grep -c '^*'
> 38
> 
> 1) Create gentoo patchsets only for finished releases and separate into 
> different sources
No there are MANY different needs and the 40 (will be) possible sources 
are here to fullfill them.
> 2) Provide vanilla kernels as unaltered, unpatched and uncustomised 
> sources just as they would be if done manually
They are present and you asked it before.
> 3) Agree on prerequisites that must be fulfilled prior to adding new 
> kernels-sources or in fact any new packages onto portage.
Already present currently we are testing and polling people about 2.6 
ppc kernel, and it is needed if we want to start working on 2.6 livecds, 
ppc970 support and other nice points in our todo...
> 
> -------------------------
> Scenario 5: Ebuild speech
> -------------------------> 
> My requests:
> 
> 1) Eliminate all use of sleep in ebuilds
no if they are present there is a reason...
> 2) Eliminate all use of beeps via echo -ne "\a"
same as 1
> 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.
sounds interesting
> 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
there is work under the hood to mitigate the interactive problems.
> 
> Overall, I would say vanilla behaviour should always be exhibited by 
> default in all aspects of the operating system in favour of user 
> preference or dev preference.  Focus should be on instructing the user 
> on how to make a change rather than making the change and expecting the 
> user to reverse it. Exceptions are where the change is vanilla in itself 
> like providing stock kernel configs to newbie users as genkernel does.
I think that you missed the vanilla-sources...

lu_zero@utopia lu_zero $ esearch vanilla
[ Results for search key : vanilla ]
[ Applications found : 2 ]

*  sys-kernel/vanilla-sources
       Latest version available: 2.4.22
       Latest version installed: 2.4.22
       Size of downloaded files: 28,836 kB
       Homepage:    http://www.kernel.org/ http://www.gentoo.org/
       Description: Full sources for the Linux kernel

*  sys-kernel/vanilla-prepatch-sources
       Latest version available: 2.4.23_pre7
       Latest version installed: [ Not Installed ]
       Size of downloaded files: 30,802 kB
       Homepage:    http://www.kernel.org/ http://www.gentoo.org/
       Description: Full sources for the prerelease vanilla Linux kernel


> 
> Please discuss as you wish.  I would be grateful if these issues were 
> paid some attention and I look forward to receiving feedback whether you 
> share the same experience or have opposing views.  If any of them should 
> be filed as bugs

this is _MY_ opinion about the whole issue, sorry if I sound arsh.
You have raised a good point on point 5, the others looks to _me_ non 
issues: if you use cron you should know how to configure it, if you are 
trying kernel I expect you to have many linux-${VERSION}-${treeversion} 
dir.

PS: ok, a nice -n 20 if not already present may be added to make the 
procedure less painful

> 
> with sincere regards
> Dhruba Bandopadhyay

hi

lu

-- 
Luca Barbato
Developer
Gentoo Linux				http://www.gentoo.org/~lu_zero




--
gentoo-dev@gentoo.org mailing list

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

[Markus Nigbur]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Sun, 2 Nov 2003 21:16:52 -0500
Jon Portnoy <avenj@gentoo.org> wrote:

> > -------------------------
> > Scenario 5: Ebuild speech
> > -------------------------
> > 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 especially 
> 
> Except that it sleeps for _very important messages_. Those timers are 
> there because people were totally missing those messages.

I can't imagine anyone who missed those messages before will read the
now, just because we added a sleep and maybe even beeps to it.
IMHO those messages are only missed during emerge -u/e world, because
you probably won't sit there hours or days, waiting for some important
message, but hey... You still don't sit there if it beeps and sleeps!

-- 
Markus Nigbur
Gentoo Developer
http://www.gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Philippe Coulonges]

Le Mon, 3 Nov 2003 17:36:12 +0100
Markus Nigbur <pYrania@gentoo.org> écrivait :

> I can't imagine anyone who missed those messages before will read the
> now, just because we added a sleep and maybe even beeps to it.
> IMHO those messages are only missed during emerge -u/e world, because
> you probably won't sit there hours or days, waiting for some important
> message, but hey... You still don't sit there if it beeps and sleeps!

What about sending the messages in a log file while some packets are not
yet emerged and then cat the whole at the end ?

No beep, no message lost.

CU
CPHIL
-- 
The whole world is about three drinks behind.
	-- Humphrey Bogart

--
gentoo-dev@gentoo.org mailing list

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

[Caleb Tennis]

On Monday 03 November 2003 12:02 pm, Philippe Coulonges wrote:
> What about sending the messages in a log file while some packets are not
> yet emerged and then cat the whole at the end ?

You, I, and a LOT of other people would like this feature.

http://bugs.gentoo.org/show_bug.cgi?id=11359

Caleb


--
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1397 bytes --]

On Monday 03 November 2003 10:58, Matthew Kennedy wrote:
> > 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

/etc/issue.logo :p
but anyways ... asking for a blank /etc/issue is wrong imo ... every distro 
has an issue, Gentoo gets one ... it's a basic file that every distro should 
have by default ...
if you dont like it, make it a 0 byte file ... next time you update baselayout 
it'll ask if you want to update /etc/issue, you just say no :p

> > 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 dont like the sleep/beeps either and there is a bug open about einfo 
logging ... go make some noise on it because it seems it's gone neglected by 
the portage team
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

On Mon, 2003-11-03 at 10:58, Matthew Kennedy wrote:
> Dhruba Bandopadhyay <dhruba@codewordt.co.uk> writes:
> >    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!!!

I'm a little surprised nobody has pointed out the ACCEPT_LICENSE
variable in make.conf yet.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 855 bytes --]

On Monday 03 November 2003 13:40, Donnie Berkholz wrote:
> On Mon, 2003-11-03 at 10:58, Matthew Kennedy wrote:
> > Dhruba Bandopadhyay <dhruba@codewordt.co.uk> writes:
> > >    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!!!
>
> I'm a little surprised nobody has pointed out the ACCEPT_LICENSE
> variable in make.conf yet.

umm ACCEPT_LICENSE has been pointed out in other threads (specifically the one 
where the id/EULA violation was originally discussed) and can be found in a 
semi-old bug: http://bugs.gentoo.org/show_bug.cgi?id=17367
if you mean to say that the variable actually does something, then you'd be 
wrong ... there is no code behind that variable atm ...
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

On Mon, 2003-11-03 at 19:55, Mike Frysinger wrote:
> On Monday 03 November 2003 10:58, Matthew Kennedy wrote:
> > > 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
> 
> /etc/issue.logo :p
> but anyways ... asking for a blank /etc/issue is wrong imo ... every distro 
> has an issue, Gentoo gets one ... it's a basic file that every distro should 
> have by default ...
> if you dont like it, make it a 0 byte file ... next time you update baselayout 
> it'll ask if you want to update /etc/issue, you just say no :p
> 

I am not going to cover the whole issue, as it seems enough people have
already 8), but I should comment on the issue thing.

Apart from it not even advertising Gentoo (hmm, think I should add
it *g* ), it is asked for for.  I have closed many bugs about it before
giving in (and then doing it good with /etc/issue.logo =), and I am sure
and I am going to get twice as many if it is removed again, as the
president was created.


No, this is not my .02, but what I will do until I get told officially
to change it, or there is a poll and 10,000 users vote against 8)

Cheers,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Mon, 2003-11-03 at 13:47, Mike Frysinger wrote:
> umm ACCEPT_LICENSE has been pointed out in other threads (specifically the one 
> where the id/EULA violation was originally discussed) and can be found in a 
> semi-old bug: http://bugs.gentoo.org/show_bug.cgi?id=17367
> if you mean to say that the variable actually does something, then you'd be 
> wrong ... there is no code behind that variable atm ...
> -mike

I have ACCEPT_LICENSE="SAVAGE" in make.conf, and emerge savagedemo does
not show a license or force me to agree to anything. Thus I would say
the lack of interactivity is preserved and there is indeed code behind
it, unless some other force I'm unaware of is at work.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jesper Fruergaard Andersen]

On Monday 03 November 2003 12:29, Dhruba Bandopadhyay wrote:

> 1) Remove slocate from base system
> 2) Remove makewhatis from daily cron duties
> 3) Remove updatedb from daily cron duties

4) Nice updatedb by default. That way it shouldn't bother to much.

> 1) Eliminate /etc/issue and rename it if it must be added to the system

2) Have the option to say that I don't want this config file from package xxx 
or any config file from package xxx. It is annoying to have configuration 
files from a package that you know how to configure yourself and maybe have 
changed a lot put on the system every time you update. Yes, you can just 
delete them, but it is still annoying.

-- 
Jesper
 23:18:52 up  1:49,  1 user,  load average: 0.10, 0.04, 0.01



--
gentoo-dev@gentoo.org mailing list

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

[Troy Dack]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, 2003-11-04 at 17:31, Jesper Fruergaard Andersen wrote:
> > 1) Eliminate /etc/issue and rename it if it must be added to the system
> 
> 2) Have the option to say that I don't want this config file from package xxx 
> or any config file from package xxx. It is annoying to have configuration 
> files from a package that you know how to configure yourself and maybe have 
> changed a lot put on the system every time you update. Yes, you can just 
> delete them, but it is still annoying.

I think that would introduce far too much overhead into portage.

-- 
Troy Dack		Gentoo moves pretty fast; if you don't stop and
tad@gentoo.org		look around once in awhile, you could miss out.

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96  92E5 FD89 16F9 4D90 BE3C
 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Troy Dack]

On Mon, 2003-11-03 at 12:29, Dhruba Bandopadhyay wrote:
> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------
> Out of the blue my hard drive starts roaring flat out.  This happens 
> generally after the first reboot after installation or every day on a 
> working system.  Given that this happens without any prior warning or any 
> explicit consent or instruction during any part of install or configuration 
> it can become extremely unpleasant especially if doing something rather 
> important and resource intensive.  The culprit here is slocate and the 
> makewhatis and updatedb cron scripts added to the daily cron duties!  One of 
> the reasons I use Linux is because it only does things when I tell it to. 
> Problems like this one sadly resemble Windows which when idle begins to 
> grind away at hidden activities.  updatedb also requires root access to kill 
> which can be an added hassle.  My requests:
> 
> 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.

qpkg and etcat do not handle any files in /home/$USER

locate does.

If you don't like having slocate as part of the default install then
create your own profile (instead of default-x86-1.4) and remove slocate
from the profile.  Maximum flexibility is available here.

> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
> With every emerge or update of baselayout or invocation of emerge -e a file 
> called /etc/issue is placed on my system.  It serves no purpose other than 
> to tell me what I already know such as what kernel, architecture and machine 
> name I am using.  And on server machines with no monitor it does not even do 
> that much.  Every time I have to delete this file and it gets added back in 
> later.  Is this an example of 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:
> 
> 1) Eliminate /etc/issue and rename it if it must be added to the system

http://www.pathname.com/fhs/2.2/fhs-3.7.html section 3.7.3

Yes, it is optional.

Since you state that on server machines with no monitor it really
doesn't serve a purpose, I'd have to assume that you never (rarely) see
it.  However you seem to be overly concerned about a 30 byte file (or a
4K file if you count the block size).


<el snippo>
 ... others have commented better than I could possibly hope to
</el snippo>

> -------------------------
> Scenario 5: Ebuild speech
> -------------------------
> 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 especially 
> where claims about speed are made not only of portage but also the packages 
> themselves what is the point in gaining ~10 seconds load time when you lose 
> ~15 seconds compile time?  What is the net gain?

Sheesh! 15 seconds compile time is not such a big deal, really.  Load
time and compile time are not comparable either.  And if you are
building on low end hardware, 15 seconds is hardly going to make a huge
difference to a 20 hour compile

>   To make matters worse, 
> ebuilds beep out loud through pc speaker on important sys-apps merges whilst 
> sleeping in between which can make one very uncomfortable in office or quiet 
> environments.

Remove the speaker :) or with a 2.6 kernel don't build support for the
speaker into the kernel.

>   I understand it is important to get messages to the user but 
> this is not the way.  There should be other means whereby all messages are 
> accumulated and logged and displayed at the end of all merges (bugs are 
> open).  I currently this as follows.
> 
> $ emerge -Du world | tee updates.log
> $ grep '01m' updates.log  ( <-- this gives all messages in log file without 
> use of sleep)
> 
> My requests:
> 
> 1) Eliminate all use of sleep in ebuilds
> 2) Eliminate all use of beeps via echo -ne "\a"
> 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.
> 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.

I believe that there are a few bugs on this, hopefully your comments
will encourage the portage devs to implement a better
logging/notification facility.

>   It's a shame that finally EULA's have made ebuilds 
> interactive and sound and message waits are further increasing merge time

Unfortunately not all the software that people want to use on their
Gentoo system is free/OSS, there has to be a compromise somehow.

> Overall, I would say vanilla behaviour should always be exhibited by default 
> in all aspects of the operating system in favour of user preference or dev 
> preference.  Focus should be on instructing the user on how to make a change 
> rather than making the change and expecting the user to reverse it. 

After using several different Linux distributions I'd have to say that
Gentoo, by and large, does things more "vanilla" than most. 
Additionally I've found Gentoo to be the easiest distribution to
customise to *my* liking, and those changes stick and are not wiped out
by a package upgrade.

> Exceptions are where the change is vanilla in itself like providing stock 
> kernel configs to newbie users as genkernel does.

OK, now you are taking _some_ control away from the user by supplying a
default config, couldn't /etc/issue be considered a default *Gentoo*
configuration (heck it is on many other distributions)?

When I first started using Gentoo I had to compile my kernel from
scratch, it taught me a good deal about my system and what it needed. 
Personally I don't think that genkernel is a good idea, but others do
and I'm all for making Gentoo more accessible to new users, so each to
their own.

> Please discuss as you wish.  I would be grateful if these issues were paid 
> some attention and I look forward to receiving feedback whether you share 
> the same experience or have opposing views.  If any of them should be filed 
> as bugs
> 
> with sincere regards
> Dhruba Bandopadhyay

-- 
Troy Dack					http://linux.tkdack.com
<troy@tkdack.com>				http://webportage.sf.net

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96  92E5 FD89 16F9 4D90 BE3C


--
gentoo-dev@gentoo.org mailing list

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

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 549 bytes --]

 I'd rather not see the suggestion of creating new profiles myself, unless you 
guys want to be fielding that many more bugs. While it is possible to do so, 
a new profile would have to be stored elsewhere or restricted from the rsync, 
not to mention the combination of packages needed and all kinds of cans of 
worms being opened there. Plus overall, doesn't it seem like a sledgehammer 
approach to smacking a gnat?  
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 875 bytes --]

On Tuesday 04 November 2003 08:08, Troy Dack wrote:
> On Tue, 2003-11-04 at 17:31, Jesper Fruergaard Andersen wrote:
> > > 1) Eliminate /etc/issue and rename it if it must be added to the system
> >
> > 2) Have the option to say that I don't want this config file from package
> > xxx or any config file from package xxx. It is annoying to have
> > configuration files from a package that you know how to configure
> > yourself and maybe have changed a lot put on the system every time you
> > update. Yes, you can just delete them, but it is still annoying.
>
> I think that would introduce far too much overhead into portage.

What about a variable INSTALL mask that would mask all files that cannot be 
installed. (/etc/fstab is a good example too)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 864 bytes --]

On Tuesday 04 November 2003 09:04, C. Brewer wrote:
>  I'd rather not see the suggestion of creating new profiles myself, unless
> you guys want to be fielding that many more bugs. While it is possible to
> do so, a new profile would have to be stored elsewhere or restricted from
> the rsync, not to mention the combination of packages needed and all kinds
> of cans of worms being opened there. Plus overall, doesn't it seem like a
> sledgehammer approach to smacking a gnat?

I agree that creating a new profile is not that easy. It just needs to go in 
/etc/make.profile. You could automatically create it from the existing profile 
with a simple grep script and symlinks for the unchanged files. This would 
not be that much of a hassle.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Thomas de Grenier de Latour]

On Tue, 04 Nov 2003 18:08:44 +1100
Troy Dack <tad@gentoo.org> wrote:

> > 2) Have the option to say that I don't want this config file from
> > package xxx or any config file from package xxx. It is annoying to
> > have configuration files from a package that you know how to
> > configure yourself and maybe have changed a lot put on the system
> > every time you update. Yes, you can just delete them, but it is
> > still annoying.
> 
> I think that would introduce far too much overhead into portage.
> 

I don't think so. In fact, I've already started to add a MERGE_EXCLUDE
(and MERGE_EXCLUDE_MASK) to portage. It's almost finished, and
really won't be a "big" change to portage. In theory, it may slow down
the merge process if you have many entries in this variables, but I
personnaly have not seen the difference during my tests. 

  I've started this because of the discussion that happens here a few
days ago, where some people asked how to avoid portage installing
info, man, or doc files. But using it to prohibit /etc/issue or
/etc/cron.daily would work just the same.

I will try to finish it tonight, and will probably post back tomorrow.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

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

[Christian Birchinger]

Yes, the same feature would be used to block installs into
/usr/share/doc or /usr/share/info. I think we called it
INSTALL_PROTECT in the previous discution about "noman" etc.
I know a totaly different topic but could be done with the same
portage feature.

On Tue, Nov 04, 2003 at 11:03:03AM +0100, Paul de Vrieze wrote:
Content-Description: signed data
> On Tuesday 04 November 2003 08:08, Troy Dack wrote:
> > On Tue, 2003-11-04 at 17:31, Jesper Fruergaard Andersen wrote:
> > > > 1) Eliminate /etc/issue and rename it if it must be added to the system
> > >
> > > 2) Have the option to say that I don't want this config file from package
> > > xxx or any config file from package xxx. It is annoying to have
> > > configuration files from a package that you know how to configure
> > > yourself and maybe have changed a lot put on the system every time you
> > > update. Yes, you can just delete them, but it is still annoying.
> >
> > I think that would introduce far too much overhead into portage.
> 
> What about a variable INSTALL mask that would mask all files that cannot be 
> installed. (/etc/fstab is a good example too)
> 
> Paul
> 
> -- 
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@gentoo.org
> Homepage: http://www.devrieze.net



--
gentoo-dev@gentoo.org mailing list

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Tue, 2003-11-04 at 08:31, Jesper Fruergaard Andersen wrote:
> On Monday 03 November 2003 12:29, Dhruba Bandopadhyay wrote:
> 
> > 1) Remove slocate from base system
> > 2) Remove makewhatis from daily cron duties
> > 3) Remove updatedb from daily cron duties
> 
> 4) Nice updatedb by default. That way it shouldn't bother to much.
> 
> > 1) Eliminate /etc/issue and rename it if it must be added to the system
> 
> 2) Have the option to say that I don't want this config file from package xxx 
> or any config file from package xxx. It is annoying to have configuration 
> files from a package that you know how to configure yourself and maybe have 
> changed a lot put on the system every time you update. Yes, you can just 
> delete them, but it is still annoying.


 # > /etc/issue

I promise portage wont touch it again without your consent.  So what is
the issue 8) ?


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Tue, 2003-11-04 at 12:03, Paul de Vrieze wrote:
> On Tuesday 04 November 2003 08:08, Troy Dack wrote:
> > On Tue, 2003-11-04 at 17:31, Jesper Fruergaard Andersen wrote:
> > > > 1) Eliminate /etc/issue and rename it if it must be added to the system
> > >
> > > 2) Have the option to say that I don't want this config file from package
> > > xxx or any config file from package xxx. It is annoying to have
> > > configuration files from a package that you know how to configure
> > > yourself and maybe have changed a lot put on the system every time you
> > > update. Yes, you can just delete them, but it is still annoying.
> >
> > I think that would introduce far too much overhead into portage.
> 
> What about a variable INSTALL mask that would mask all files that cannot be 
> installed. (/etc/fstab is a good example too)
> 

Use dispatch-conf - it keeps a record what you want to do, and should
not bother you again if it is not something major.


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

On 11/04/03  Donnie Berkholz wrote:

> On Mon, 2003-11-03 at 13:47, Mike Frysinger wrote:
> > umm ACCEPT_LICENSE has been pointed out in other threads
> > (specifically the one where the id/EULA violation was originally
> > discussed) and can be found in a semi-old bug:
> > http://bugs.gentoo.org/show_bug.cgi?id=17367
> > if you mean to say that the variable actually does something, then
> > you'd be wrong ... there is no code behind that variable atm ...
> > -mike
> 
> I have ACCEPT_LICENSE="SAVAGE" in make.conf, and emerge savagedemo
> does not show a license or force me to agree to anything. Thus I would
> say the lack of interactivity is preserved and there is indeed code
> behind it, unless some other force I'm unaware of is at work.

There is some code in the eutils eclass, but nothing in portage itself.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Steven Elling]

On Sunday 02 November 2003 20:01, Brad House wrote:
> 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.

I think the Gentoo team should consider giving the user a way of configuring 
packages to not install certain cron jobs upon install.  For instance, I 
have a Tecra 8000 laptop that I use every once in a while.  After the 
laptop completes booting, I cannot use it for 30 minutes to a hour because 
the makewhatis and updatedb (or slocate) cron jobs kick off after booting 
and drag the system to a crawl.

And yes, I know I can just remove the cron jobs but by the time I'm done 
with the laptop I forget to remove them.  Also, the cron jobs will get 
installed again when their packages are upgraded.

Better yet.  Why not do some magic in portage to run makewhatis and updatedb 
automagically after a world or system update -- maybe as a FEATURES setting 
-- and remove the cron jobs altogether.  After all, 90% - 99% of the time 
files and man pages are only added to Gentoo systems when emerging packages 
(Hmm. deja-Vu).

I think it is pointless to run programs to update databases that don't need 
it, which is for the most part the current configuration.  Note, Gentoo 
isn't the only distro using package management tools that does this.


--
gentoo-dev@gentoo.org mailing list

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

[William Kenworthy]

Not a good idea.  slocates purpose is not just portage.  Its used on a
running system to allow users to easily and quickly find any file. 
Hence its run daily as users tend to create/delete files each day.

Your circumstance is not the most common one - not using linux all the
time.  servers and user systems benefit from these facilities, both for
the admin and users in general.  I also use a laptop and know what you
mean, and would be lost without an up-to-date locate with over 6Gbytes
of data files in my home directory - it does slow things down if you
dont "nice" it though.

BillK

On Wed, 2003-11-05 at 07:06, Steven Elling wrote:
> On Sunday 02 November 2003 20:01, Brad House wrote:
> > Commenting below:

> I think the Gentoo team should consider giving the user a way of configuring 
> packages to not install certain cron jobs upon install.  For instance, I 
...
> Better yet.  Why not do some magic in portage to run makewhatis and updatedb 
> automagically after a world or system update -- maybe as a FEATURES setting 
> -- and remove the cron jobs altogether.  After all, 90% - 99% of the time 
> files and man pages are only added to Gentoo systems when emerging packages 
> (Hmm. deja-Vu).



--
gentoo-dev@gentoo.org mailing list

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

[Anthony de Boer]

Jon Portnoy wrote:
> Many, many users use locate and many would complain if it was missing. 

On a box where only I have a shell, and never use slocate, it's not
needed and does get annoying when cron kicks in.  This is probably a very
good example of something where people can agree to disagree. and having
a well-documented switch is a good thing.

>  ... rm /etc/cron.daily/locatedb.cron ...

That does it, though chmod -x would be less fatal and more reversible.  I
prefer to actually remove the package, though emerge insists on wanting to
put it back in when I update world, so we're having a wrestling match.

It's probably with good reason that I'm hesitant to muck with profiles.

> > 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 especially 
> 
> Except that it sleeps for _very important messages_. Those timers are 
> there because people were totally missing those messages.

Except that *I* sleep for _very long compiles_.  :-)

Also, I frequently emerge multiple packages at once, and only the last's
tail will still be on my screen when I come back.  Even when I'm awake,
I rarely sit and watch the build go by.

It might be good to have a batch flag to ebuild or in FEATURES that says
not to bother with sleep-and-beep because nobody is around.

Some tools to find the Very Important Messages in PORT_LOGDIR's copious
output (I have 42 meg of build output there right now) would be helpful. 
Ideally I'd be able to come back to the computer and review all the
messages from recently-completed builds.

Storing the important messages in a release-notes file under
/var/db/pkg/*/*, so they're with the build permanently, might also be a
worthy idea.

-- 
Anthony de Boer

--
gentoo-dev@gentoo.org mailing list

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

[Terje Kvernes]

Steven Elling <ellings@kcnet.com> writes:

  [ ... ]

> I think the Gentoo team should consider giving the user a way of
> configuring packages to not install certain cron jobs upon install.
> For instance, I have a Tecra 8000 laptop that I use every once in a
> while.  After the laptop completes booting, I cannot use it for 30
> minutes to a hour because the makewhatis and updatedb (or slocate)
> cron jobs kick off after booting and drag the system to a crawl.

  first, slocate I/O shouldn't be able to bring your box to a crawl.
  secondly, you're free to kill the processes while they're running.
 
> And yes, I know I can just remove the cron jobs but by the time I'm
> done with the laptop I forget to remove them.  Also, the cron jobs
> will get installed again when their packages are upgraded.

  inject an ebuild with a version number high enough that you won't
  ever see it again.

  [ ... ] 

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

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

[Camille Huot]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

On Tue, 4 Nov 2003 19:43:14 -0500
Anthony de Boer <gentoo-dev@lists.leftmind.net> wrote:

> Jon Portnoy wrote:
> > Many, many users use locate and many would complain if it was
> > missing. 
> 
> On a box where only I have a shell, and never use slocate, it's not
> needed and does get annoying when cron kicks in.  This is probably a
> very good example of something where people can agree to disagree. and
> having a well-documented switch is a good thing.
> 
> >  ... rm /etc/cron.daily/locatedb.cron ...
> 
> That does it, though chmod -x would be less fatal and more reversible.
> I prefer to actually remove the package, though emerge insists on
> wanting to put it back in when I update world, so we're having a
> wrestling match.

emerge inject is your friend

> It's probably with good reason that I'm hesitant to muck with
> profiles.
> 
> > > 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 especially 
> > 
> > Except that it sleeps for _very important messages_. Those timers
> > are there because people were totally missing those messages.
> 
> Except that *I* sleep for _very long compiles_.  :-)

I totally agree these sleeps are not the good way. We're waiting for the
buffered messages to the end of the emerge process .. _that_ should
solve the problem. (don't forget to remove the beeps too)

> Also, I frequently emerge multiple packages at once, and only the
> last's tail will still be on my screen when I come back.  Even when
> I'm awake, I rarely sit and watch the build go by.
> 
> It might be good to have a batch flag to ebuild or in FEATURES that
> says not to bother with sleep-and-beep because nobody is around.
> 
> Some tools to find the Very Important Messages in PORT_LOGDIR's
> copious output (I have 42 meg of build output there right now) would
> be helpful. Ideally I'd be able to come back to the computer and
> review all the messages from recently-completed builds.
> 
> Storing the important messages in a release-notes file under
> /var/db/pkg/*/*, so they're with the build permanently, might also be
> a worthy idea.
> 
> -- 
> Anthony de Boer
> 
> --
> gentoo-dev@gentoo.org mailing list
> 


-- 
Camille Huot - <cam@cameuh.net>
direct contact on #igoan at irc.freenode.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 05 November 2003 02:00, Terje Kvernes wrote:
> Steven Elling <ellings@kcnet.com> writes:
>
>
>   first, slocate I/O shouldn't be able to bring your box to a crawl.
>   secondly, you're free to kill the processes while they're running.

Unfortunately it does. I think that the 2.6 kernel will probably improve 
this, but currently updatedb effectively locks most disk i/o

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/qMHWbKx5DBjWFdsRArAzAKCTVyQqLp+JTqV1m1q+h/9JUXC1XwCeJ0Mq
0JXW5f3QBC57CkJyf195Rfg=
=GwrT
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

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

[Thomas de Grenier de Latour]

On Tue, 4 Nov 2003 12:49:26 +0100
Christian Birchinger <joker@gentoo.org> wrote:

> Yes, the same feature would be used to block installs into
> /usr/share/doc or /usr/share/info. I think we called it
> INSTALL_PROTECT in the previous discution about "noman" etc.
> I know a totaly different topic but could be done with the same
> portage feature.

If you want you can try this patch:
http://bugs.gentoo.org/show_bug.cgi?id=32780

But sorry, I've called it "MERGE_EXCLUDE", because I've made the
first version of this patch before the consensus on the name, and was
too lazy to change it :)

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

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

[Terje Kvernes]

Paul de Vrieze <pauldv@gentoo.org> writes:

> On Wednesday 05 November 2003 02:00, Terje Kvernes wrote:
> 
> > first, slocate I/O shouldn't be able to bring your box to a crawl.
> > secondly, you're free to kill the processes while they're running.
> 
> Unfortunately it does. I think that the 2.6 kernel will probably
> improve this, but currently updatedb effectively locks most disk i/o

  there is a difference, even under 2.4, between brining a box to a
  total crawl and to lock most disk I/O.  :-)

  that being said, 2.6.0 is nicer in this regard, which is one of the
  reasons I run 2.6. 

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

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

[Christian Birchinger]

I guess no one cares about the name as long as the feature is
there.

On Wed, Nov 05, 2003 at 11:48:33AM +0100, Thomas de Grenier de Latour wrote:
> On Tue, 4 Nov 2003 12:49:26 +0100
> Christian Birchinger <joker@gentoo.org> wrote:
> 
> > Yes, the same feature would be used to block installs into
> > /usr/share/doc or /usr/share/info. I think we called it
> > INSTALL_PROTECT in the previous discution about "noman" etc.
> > I know a totaly different topic but could be done with the same
> > portage feature.
> 
> If you want you can try this patch:
> http://bugs.gentoo.org/show_bug.cgi?id=32780
> 
> But sorry, I've called it "MERGE_EXCLUDE", because I've made the
> first version of this patch before the consensus on the name, and was
> too lazy to change it :)

--
gentoo-dev@gentoo.org mailing list

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

[Anthony de Boer]

Terje Kvernes wrote:
>   inject an ebuild with a version number high enough that you won't
>   ever see it again.

For some reason emerge isn't fooling itself:

# emerge --inject sys-apps/slocate-999.9
...

# emerge -up --deep world
...
[ebuild  N    ] sys-apps/slocate-2.7-r2
...

-- 
Anthony de Boer

--
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On 11/06/03  Anthony de Boer wrote:

> Terje Kvernes wrote:
> >   inject an ebuild with a version number high enough that you won't
> >   ever see it again.
> 
> For some reason emerge isn't fooling itself:
> 
> # emerge --inject sys-apps/slocate-999.9
> ...
> 
> # emerge -up --deep world
> ...
> [ebuild  N    ] sys-apps/slocate-2.7-r2
> ...

Yeah, "system" packages are hard to get rid off. Injecting 2.7-r99
should keep slocate from your system until there is a new version, the
real solution would be some kind of overlay or stacked profiles, however
that's not trivial and needs careful planning.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Steven Elling]

On Tuesday 04 November 2003 17:54, William Kenworthy wrote:
> Not a good idea.  slocates purpose is not just portage.  Its used on a
> running system to allow users to easily and quickly find any file.
> Hence its run daily as users tend to create/delete files each day.


I know what slocate and updatedb are used for.

I'll explain my point of view.  I view slocate and updatedb as utilities to 
help a user find system files NOT user files.  I view the command 'find' as 
the utility of choice for finding user files.

The reason I have this view is because I am a security aware individual.  I 
set up slocate or updatedb so that it will not catalog files located in 
/tmp, /usr/tmp, /var/tmp, /mnt, /root, /usr/src, /var/spool, and /home.  I 
also set users home directories to 0700.  In this scenario, running slocate 
or updatedb daily is pointless, unless of course you update/install 
packages on your system every day.

I didn't say slocate's purpose was for portage,  I was just saying that in 
scenarios similar to mine it would be better to run or schedule slocate / 
updatedb after a world or system update because that is the only time 
cataloged files would change.


> Your circumstance is not the most common one - not using linux all the
> time.  servers and user systems benefit from these facilities, both for
> the admin and users in general.  I also use a laptop and know what you
> mean, and would be lost without an up-to-date locate with over 6Gbytes
> of data files in my home directory - it does slow things down if you
> dont "nice" it though.

I tried to nice the programs but it doesn't seem to help my laptop.  The 
system still slows to a crawl but then again I am talking about a Tecra 
8000.  I wish I could afford new hardware but being laid-off for about a 
year and a half with a mound of debt doesn't help.


--
gentoo-dev@gentoo.org mailing list

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

[Steven Elling]

On Tuesday 04 November 2003 19:00, Terje Kvernes wrote:
>
>   first, slocate I/O shouldn't be able to bring your box to a crawl.
>   secondly, you're free to kill the processes while they're running.

Well, slocate does bring my system to a crawl.  More than likely due to the 
crappy/old hardware Gentoo is on.  If I have to get something done I 
usually did kill the processes but as of late I just moved the cron jobs to 
weekly.

>   inject an ebuild with a version number high enough that you won't
>   ever see it again.

I really don't want to resort to this because security flaws could exist in 
slocate that I may not be made aware of.


--
gentoo-dev@gentoo.org mailing list

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

[Eldad Zack]

> >   inject an ebuild with a version number high enough that you won't
> >   ever see it again.
> 
> I really don't want to resort to this because security flaws could exist in 
> slocate that I may not be made aware of.

well, if you unmerge slocate and inject a high enough version of slocate, 
it just won't exist on your system, just on portage's database, so it won't 
try to merge slocate on emerge world.





--
gentoo-dev@gentoo.org mailing list

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

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

begin  quote
On Fri, 7 Nov 2003 17:24:07 -0600
Steven Elling <ellings@kcnet.com> wrote:



> The reason I have this view is because I am a security aware
> individual.  I  set up slocate or updatedb so that it will not catalog
> files located in  /tmp, /usr/tmp, /var/tmp, /mnt, /root, /usr/src,
> /var/spool, and/home.  I also set users home directories to 0700.  In
> this scenario, running slocate  or updatedb daily is pointless, unless
> of course you update/install packages on your system every day.


I think that since you are an admin, and experienced at reconfiuring
slocate for your needs, makes you capable of moving or disabling the
cron jobs, so that shouldn't be an issue for you.



> 
> I didn't say slocate's purpose was for portage,  I was just saying
> that in  scenarios similar to mine it would be better to run or
> schedule slocate /   updatedb after a world or system update because
> that is the only time cataloged files would change.

Aye, perhaps. in cases like that I think its easier if you just hook
slocate to check the mtime on the counter file for portage, compare with
last time's and run if they differ.   Either that, or patch emerge to
fork a slocate after each time things are installed.


-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]