Bugzilla Bug 7144

Several things:

First, there is no mention of logrotate, or equivalent functionality in
the install instructions.  This seems like a pretty large oversight since
without a log rotation scheme, the disk is going to fill up eventually
any it will be "our" fault since we never told the "user" that they needed
to do something about it.

Second, once the user figures out that they need log rotation, they may try
to "emerge logrotate" and find that it doesn't actually *do* anything out
of the box (so to speak).  I think the cron file and logrotate.conf files
should be installed into /etc/cron.daily and /etc respectively.  At least
then, the user has something to start from.  Better yet, this is Gentoo
Linux after all, we're supposed to be the hot stuff here.  Why not include
a functional logrotate.conf that's closer to what people might want?

Third, the default logrotate.conf uses the include functionality of
logrotate to grab files from /etc/logrotate.d.  The ebuild script doesn't
create this directory.

Az, thoughts on this?

how about a nice explain how to do text after emerging ?

 einfo in the ebuild

For the second point, I agree in that there should be a base logrotate.conf
based on the default daemons, etc which are installed.

On the third point, getting logrotate up and running is a major PITA w/o any
predefined scripts.  I would be nice, but admittedly a ton of work, to populate
each of the currently available daemon with its own script for logrotate.d.

Perhaps a USE flag, logrotate, could be used to determine if the "extras" get
installed?

Guess I never thought about it, as I use sysklogd with vcron, which
rotates logs nicely all by itself.

Nicholas, you are the lucky canditate that can add the scripts, as it seems
you sorda know something about them :P

Already one step ahead of you, I've modified (locally) the logrotate ebuild to
install properly along with a default conf and cron script.  I've also been
"stealing" logrotate.d scripts from RedHat's rpm's.  I will add them to
ebuilds, but I need to know first if we should have a USEFLAG to determine
their installation?  Or should I just check for the existance of
/etc/logrotate.d?  Please advise.

I think just install them.  They usually are small, and the user who
use logrotate will delete/enable those he need.  Rather that, than
confusion about them not being there.

Here's the /etc/logrotate.d/syslog-ng I'm using here:

/var/log/messages /var/log/mail.log /var/log/mail.err /var/log/kern.log /var/log/auth.log /var/log/cron.log {
    sharedscripts
    postrotate
	/etc/init.d/syslog-ng reload > /dev/null 2>&1 || true
    endscript
}

Dragon, how's it going on this?

I'm working on it when I can (as you are aware I do have a fairly full plate),
but there are a bunch of packages which need the logrartate config fragments. 
I would prefer to check the majority of these fragments in at once so that
there is some uniformity.  I also want to make sure I get as much coverage as I
can on this first round.  Also, I would like Martin to add /etc/logrotate.d to
baselayout since he wants the fragments installed regardless of whether the
person uses logrotate or not.  Once the baselayout with this dir is stable, I
will then commit the updated ebuilds and logrotate config fragments.  However,
if this is an issue, let me know and I'll devote more resources to completing
it.

To be honest, I would suggest a WIB (worse-is-better) approach.  I think that
if
we have some known culprits, we should get a first pass out there and not worry
about the stragglers.  We'll bring them into the fold as we can, but it might
be
too much to attempt to get a wide range of packages on the first pass.

Regarding /etc/logrotate.d, there is no need whatsoever to wait for the 
baselayout change.  The first package to add a snippet will automatically
create
that directory (as you know) and a subsequent baselayout update won't hurt
anything.  It's not a bad idea to get logrotate.d into baselayout, but I don't
think that should hold us up.

If there's anything I can do to help out, let me know.  If you have some
starter
snippets, maybe you should add them as attachments here so you're not the only
one with the info...  ;-)

Right, I do not see what baselayout have to do with this ... it should actually
be created initially by logrotate (maybe with keepdir ...).

Created an attachment (id=8992) [edit]
A logrotate ebuild.

I improved the logrotate ebuild before I found this bug, so I'll go ahead and
include it here, just in case it has something that you'll find useful.  It has

the following changes:

+ Silences the CVS/Root spewage in the 3.6.5 "make" output.
+ Don't twiddle the Makefile, just set RPM_OPT_FLAGS with our CFLAGS
  (note that the tweaking of the Makefile was in the wrong section
  anyway -- it would have gotten repeated on repeated compilations if
  someone was using ebuild manually).
+ Installs a tweaked logrotate.conf file (doesn't refer to RPMs).
+ Installs a logrotate.d dir.
+ Installs a crontab file in the cron.daily dir.
+ The package now depends on virtual/cron.

Take a look if you haven't already tweak all these items.

On the topic of putting logrotate.d into the baselayout, I agree with Martin
(it just needs to be in the logrotate package).  The .keep file is needed to
prevent the directory from vanishing (which would cause logrotate to exit
with an error).  Having an empty .keep file in the dir does not adversely
affect logrotate (it reads the file, but does not do anything nor does it
complain about it being empty).

Martin, since logrotate isn't a required package, then what happens to the
people who don't have logrotate emerged but emerge a package with a logrotate
fragment?  You told me that I should just have each fragment install by
default, without any use flags or conditionals.  There's no reason why putting
it into baselayout would be bad.  It's either that or a USE flag, as we need
some way to make sure we don't get a sandbox error.

Wayne, actually I've already done those things, but thanks nontheless for your
contribution.  The reason I need logrotate.d in baselayout is because of how we
decided to impliment the installation of logrotate fragments [in this case,
without conditionals].  Besides, it just makes things easier for me.

Since Logrotate is developed by redhat, I'll be making my own tarballs based on
cvs tags rather then by rpm or debian's sources.  Anyhow, we'll get this fixed
up.

Dragon, won't the directory /etc/logrotate.d be created automatically
by any package installing a logrotate fragment?  Possibly I'm
misunderstanding something, but I don't think there is any need for
the directory to exist prior to installing fragments...

Ok, I had a real brainfart when writing that last night.  Aaron, you are
totally correct, of course portage will make the dir!  What was I thinking? 
Ok, well that solves that one, I'll just have logrotate's ebuild install the
.keep file.  Thanks for setting me straight :-).

Just FYI, I have added a logrotate.d snippet to the
syslog-ng-1.6.0_rc1-r1 ebuild based on Michael's suggestion.

Re-assign to the original bug filer since he's now a dev and can decide what
needs to be done next, if anything, to finish this out.

I was just fighting with logrotate here and had some problems. I wont speak of
them here, but, I think a solution to your question of where to place the
logrotate.d/* files would be to place them in /usr/share/logrotate-*/samples
directory. Using this method would prevent confs from being installed for
programs that do not exist on the user's system (and keep the cron log from
filling up with errors). Placing a note at the end of the ebuild explaining the
location of the confs would be beneficial as well.

Thought I'd throw in my 2 cents and see if I could get some change anyhow :)
-P

*** Bug 20907 has been marked as a duplicate of this bug. ***

Created an attachment (id=11998) [edit]
Fix a couple minor things in the 3.6.5-r1 ebuild

A couple things I noticed in the new logrotate 3.6.5-r1 ebuild:

- The src_compile() function is patching the source.  This should be done
  in the src_unpack() function so that someone using ebuild manually can
  run "ebuild ... compile" multiple times.

- The digest is missing the line for the selinux patch.

I've attached a patch that fixes these problems.

Wanye -  Thanks for the patch.  I've applied it so please try out the
latest logrotate ebuild.

Thanks for testing.

Masked testing for long enough so unmasked and closing this bug.