Bug 922769

+++ This bug was initially created as a clone of Bug #499042 +++

Description of problem:
The ppp package incorrectly requires the logrotate package.  All packages should (hopefully) be log rotation package agnostic. 


Version-Release number of selected component (if applicable):
RHEL5

How reproducible:
Every time.

Expected results:
The logrotate package should be uninstallable.

--- Additional comment from RHEL Product and Program Management on 2010-10-05 04:05:06 EDT ---

This request is not going to be addressed in RHEL 5.6 FasTrack.

--- Additional comment from RHEL Product and Program Management on 2011-04-18 07:29:21 EDT ---

This request is not going to be addressed in RHEL 5.7 FasTrack. Moving to RHEL 5.8 Fastrack.

--- Additional comment from RHEL Product and Program Management on 2011-06-22 10:04:40 EDT ---

Since the release flag was set to ? after the pm_ack and devel_ack flags were set to + (was likely set for the previous release), the pm_ack and devel_ack flags have been reset to ? by the bugbot (pm-rhel). This action ensures the proper review by Product Management.

--- Additional comment from Ondrej Vasik on 2011-08-25 08:42:44 EDT ---

dev_ack+ for 5.8 fastrack

--- Additional comment from Eduard Benes on 2011-10-06 04:59:57 EDT ---

Doing a quick check, it looks like there are still few other packages not logrotate agnostic. (see examples below)

 * Do we really want all of them to be logrotate agnostic? 
 * Is there a plan to address all of them if there is a fair justification for such change?
 * How about addressing all of them at once (not only in RHEL 5) instead of doing it just for this bug because it got filed long time ago?

On RHEL 5 rpmreaper shows:
 L      285K ┌─< conman                    0.1.9.2-8.el5.i386
 L       74K ├─< freeipmi-bmc-watchdog     0.5.1-6.el5.i386
 L      1.1M ├─< krb5-server               1.6.1-55.el5.i386
 L      770K ├─< opensm                    3.3.3-1.el5.i386
        812K ├─< ppp                       2.4.4-2.el5.i386
  o     3.6M ├─< rpm                       4.4.2.3-22.el5.i386
 lo     1.0M ├─<+rsyslog                   3.22.1-3.el5_5.1.i386
       30.4M ├─< samba                     3.0.33-3.29.el5_5.1.i386
 L      3.5M ├─< squid                     2.6.STABLE21-6.el5.i386
 L      285K ├─< vsftpd                    2.0.5-16.el5_5.1.i386
  o      55K logrotate                 3.7.4-9.el5_5.2.i386 

On RHEL 6 rpmreaper shows:
 L      391K │   ┌─< conman                    0.2.5-2.3.el6.x86_64
 L      126K │   ├─< freeipmi-bmc-watchdog     0.7.16-3.el6.x86_64
 L      1.6M │   ├─< krb5-server               1.9-8.el6.x86_64
 L      728K │   ├─< opensm                    3.3.5-1.el6.x86_64
        760K │   ├─< ppp                       2.4.5-5.el6.x86_64
        1.5M │   ├─< rsyslog                   4.6.2-3.el6.x86_64
       17.4M │   ├─< samba                     3.5.6-86.el6.x86_64
 L      331K │   ├─< vsftpd                    2.2.2-6.el6_0.1.x86_64
         82K ├─> logrotate                     3.7.8-12.el6_0.1.x86_64

--- Additional comment from Ondrej Vasik on 2011-10-06 05:16:59 EDT ---

Maybe more question for logrotate maintainer, adding him to CC. Probably worth of tracker bugzilla and addressing it in Fedora Rawhide.

--- Additional comment from Jan Kaluža on 2011-10-06 05:51:39 EDT ---

> * Do we really want all of them to be logrotate agnostic?

Hm, I think I would see some benefits for people who don't want to rotate logs (although, this can be achived by simple cron or logrotate change) or when they want to use something else (do we ship something else for general log rotation in RHEL/Fedora?).

The true is that those packages don't need logrotate for their functionality, so they could not depend on it. But I'm not sure I see "real" benefit of doing it.

If we decide to do it, it should address Rawhide at first. There are 54 packages requiring logrotate.

--- Additional comment from RHEL Product and Program Management on 2011-11-14 06:59:32 EST ---

This request is not going to be addressed in RHEL 5.8 FasTrack. Moving to RHEL 5.9 FasTrack.

--- Additional comment from RHEL Product and Program Management on 2012-03-29 05:50:39 EDT ---

Since the release flag was set to ? after the pm_ack and devel_ack flags were set to + (was likely set for the previous release), the pm_ack and devel_ack flags have been reset to ? by the bugbot (pm-rhel). This action ensures the proper review by Product Management.

--- Additional comment from Libor Miksik on 2012-08-27 04:41:52 EDT ---

This request is not going to be addressed in RHEL 5.9 FasTrack. Moving to RHEL 5.10 Fastrack.

--- Additional comment from Libor Miksik on 2012-08-27 04:48:11 EDT ---

This request is not going to be addressed in RHEL 5.9 FasTrack. Moving to RHEL 5.10 Fastrack.

--- Additional comment from RHEL Product and Program Management on 2012-08-27 04:55:27 EDT ---

This request has been proposed for two releases.  This is invalid
flag usage.  The higher numbered release flag has been cleared.
If you wish to change the release flag, you must clear one release
flag and then set the other release flag to ?.