Uninstall the process accounting package if you do not need it.
We do not support homemade kernels.  I have made a note however to try
and make if fail more gracefully in the future.

Is not supportingcustom kernels an official statement? Sorry to say, but this
another step towards a closed system, which might be a reason for me to change
the distribution.
What the heck is the kernel-source-rpm for then? If only for reference, then
root it under /usr/share/doc.
Besides, if you support psacct only with with Redhat blessed kernels, then you
might want to include a depency on the kernel package in psacct

IMHO is is not too difficult to handle slight deviations gracefully.

Sorry to say, I am a bit dissappointed by your statement.

No, this is not a step towards a closed system in any way shape or form.
You totally misunderstand my statements and have blown them out of
proportion.  "Support" is the key word here.  A user compiling their
own kernel can cause all sorts of things to break.  A homemade kernel
has not been subject to our quality assurance testing, and we cannot
support every random kernel out there compiled with every permutation
of random options with every random C compiler.  We need some quality
control in order to provide support.  This is no different from any other
vendor out there.

That does not mean that we will not help you, or try to enhance the
distribution based on suggestions you make, it means that if you rebuild
the kernel and it breaks, you get to keep both pieces.  Your request is
really an enhancement request - one that I agree with or else I would
have closed it as NOTABUG or WONTFIX.  If such a request is beneficial
to people and is not difficult to implement, and doesn't break anything,
then it certainly is reasonable to ask for, and most likely have it
implemented.

I've deferred it so I can work on it later when I am planning on updating
the psacct package.  If that is not support, I don't know what is.  I've
said I'll add the needed bits which is more or less "yes, sounds good".
What more could I possibly do?  Please do not misunderstand me, I aim
to help, not to hinder.

If you are disturbed still by my comments after reading this, perhaps Arjan,
our kernel RPM maintainer could comment better on what is meant by "support"
for kernels.  We certainly have no interest in tying anyone's hands to certain
software or we wouldn't be here.  Linux is about freedom of choice.  IMHO
Red Hat as a whole, and all of us engineers, etc. individually are here to
serve the open source community, and our customers, users, etc.  We are
always 'ears wide open' to good user contributed ideas.

If you have more suggestions such as this, please by all means submit 
more requests for enhancement against any packages you have suggestions
for.  There are very good chances that they will be beneficial to many
and integrated if they are deemed good ideas.

Thanks,
TTYL

Kernelwise, we obviously support the rpms we provided. This includes the
kernel-source RPM. If people have problems building their own kernel I will do
my best to help them with that. 

If things break when you select other options than we did, and the options are
"sane" [1], I try to help with problems. If a problem is "non-critical"  (one
mail once a month isn't super critical, although annoying) and caused by a
changed config, then fixing it for "the next package version" is something I do
for my packages, provided it doesn't interact with current setups. Critical
problems (dataloss, no operation etc) get obviously a higher priority. 


[1] with that I mean that if someone, say, disables support for the EXT2
filesystem and then complains that / doesn't mount, I'd call that NOTABUG.
Simlar reasoning for, say, enabling devfs and then complaining /dev looks
strange.

Yes, that sounds very sane to me also, and is very much how I maintain
XFree86, and other packages.  I handle critical stuff first, followed by
important stuff that affects the most number of users, etc.. down the
priority line.  Sometimes I squeak a simple quickie request in here and
there also.  If someone rebuilds XFree86 and the rpm has a problem, I
will try to fix it or offer suggestions when possible.  If someone tries
to rebuild X with a non Red Hat provided compiler however and/or with
their own custom host.def, random patches, or removed patches, and has
problems though, I scratch my head and point them to xpert
unless of course I can be helpful without going out of my way for 8
hours being a tech support guy.  ;o)  Sometimes even then I help out
anyways because I love helping people.  ;o)  Time and TODO list size,
engineering deadlines are the only constraints....  ;o)

Well, ok, this explanation sounds clearer to me. The problem is (was) that the
first answer contained nothing I did not know already. Besides, opening with an
offending statements provokes quick shots, which is what I did and apologise
for.

I know that for quality control you need a defined test bed, wich excludes
customs kernel configs that are unusable or insane in one way or another (the
problem is that I don't know of any computer implementation of common sense to
automate the decision ;-)
I am merely a bit unpleased by the recent responses to my bug (or improvement)
reports. Perhaps they are meant ok, perhaps it is because I am not a native
english speaker, but somehow the form did not please me.

Your last sentence confirms my again that Redhat has an open ear for user
requests. Having some of my ideas going into the distribution is one of my major
reasons for using Redhat. (The others are that I like the RPM package format and
being able to rebuild the whole distro on my own when I had time or need to)

So I am sorry if I took you wrong and looking forward to the next psacct release
from updates

The psacct package now contains its own initscript, and defaults to being
disabled upon installation.  Unless a user enables psacct now, it remains
off.  If a user recompiles a kernel without process accounting support, they
can now disable the feature without removing psacct.  This change is part
of our skipjack beta, and rawhide and will be in the next release.

Thanks.