Package pruning for FC4 and beyond - DRAFT FINAL

[Chuck R. Anderson]

On Sun, Feb 27, 2005 at 12:09:44AM -0500, Eric Warnke wrote:
> dovecot/cryus - IMAP server cyrus does seem more like a specialty 
> package when compared to the simplcity and utility of dovecot. OTOH 
> cyrus is maintained for RHEL and other packages depends on cyrus-sasl. 
> The community definatly appears to favor keeping dovecot and letting 
> cyrus be religated to extras.

If cyrus-sasl can't be separated easily from cyrus IMAP, then it needs
to stay.  sasl is an authentication library that is needed by many
components of LDAP/Kerberos authentication strategies.

> lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether 
> those scripts are not part of core or they are not marked correctly.  If 
> you can surf the web with either, you can download them from extras.  If 
> either has a dependancy in core the .src.rpm needs to be corrected. 
> Personally I think lynx and w3m should go to extras.

lynx should stay if it is the only one that does Basic Auth and SSL
well.  In fact, I change my stance here and say that lynx should stay
based on the argument that scripts, libraries, and applications use
it.  It existed for so long before the other text browsers, that it
has become the defacto standard way to "bootstrap" things from the
net.

> SDL - Few things depend on this. 1 objection. Would be nice to have in 
> core, but is really not a core function since nothing in core depends on 
> it.  Anything that is going to require it can pull it down from extras.
> + kdeaddons - small add on packages. not 100% necessary.
> + gstreamer-plugins
> + theora-tools

theora-tools should stay.  We need to have an unencumbered suite of
multimedia tools in Core, if for no other reason than to encourage
widespread adoption of open formats over closed ones.

> nut - nice package, but is it really core materal? 1 objection used on 
> server.  Is server use enough to keep it in core?

Yes.  Core is not just a desktop distribution.  nut should stay.

> talk - protocol is getting old with IM - 3 objections... do people still 
> use this.  Last time I saw this in active use was a decade ago.  Unlike 
> other mature tools nothing really depends on talk.  I think this is in 
> the same category as telnetd, it's just not in wide enough use to 
> justify keeping it in core.

We're talking (no pun intended) about 22k installed (50k source)
here... With 3 objections to it, why worry about it so much?  Just
keep it...

> *Recommend eviction from core*
> routed - appears to be superceeded by quagga

routed is a very simple RIP protocol daemon sometimes used by
non-routers in listen-only mode (-q) to learn the available routes on
the network (default route, other routes).  It is this aspect of
routed that maybe should keep it in Core.  Source 43 KB.  Installed 40
KB.  I say keep it.
  
quagga is really a much larger package that supports many more routing
protocols than just RIP, and is intended for large routers, route
servers, etc. not network clients, nor your simple home router.  It is
much more complex, and as such doesn't really fill the need that
routed fills.  Source 2 MB.  Installed 4+ MB.  If either package goes,
this one should.  This seems like a perfect candidate for Extras,
given its small target audience.

> dmalloc, valgrind - electricfence appears to be more compatible and 
> better developed.

I thought valgrind was supposedly so much better than the others?  I
remember at one time it had been encumbered by patents or something,
and as such it couldn't be included at the time.  Now that it is in
there, should we really remove it again?  I have no strong opinion on
this one, just asking...  Extras could certainly take this one if
desired.

> iptstate - package getting stale

Stale?  It was initially packaged in Jan 2004, and recently updated in
Feb 2005.  Again, this is only 17 KB source, 39 KB installed.  I say
keep it.  It sounds very useful.

> a2ps - text to postscript tool required by xfprint ( xfprint already in 
> extras ) no brainer

Agreed.  As long as we keep enscript.