PROPOSAL: Core size reduction "bug day"

Sun Jul 25 20:08:16 UTC 2004

On Sun, 2004-07-25 at 03:17, Lamar Owen wrote:

> * The X.org 100DPI fonts, unless and until a GUI config utility can be had to 
> easily switch between the 75DPI fonts and these. (and those that might say 
> that I just need a higher resolution to appreciate them, well, I have one 
> reply: I'm at 1400x1050 now; want me to go higher? :-))  Just how many fonts 
> need to be Core material?

You yourself raised the "one source package" problem below.
Realistically, there are many sub-packages which by themselves would
merit being moved from Core to Extras, but does it merit the extra
effort of maintaining them as separate source packages?

> * Until and unless the soundsystem can be made to use it, scrap timidity++.  
> My sound card has no wavetable, yet getting a simple configuration for 
> playing MIDI files (in KDE, which is where I live; I do not and will not 
> install GNOME for technical and practical reasons, the best of which is that 
> kmail is the best GUI e-mail package available for Linux bar none) is not 
> easily found.

Using timidity++ for a soft MIDI pseudo device would indeed be a good
idea. Could still be in Extras ;-).

> * Does anyone use the GNU Ada compiler?
> (Again, I'm talking about tossing out of Core into Extras, not about throwing 
> it out altogether).  But splitting subpackages into separate repositories 
> might prove technically challenging.

Yeah ;-).

> * Mozilla.  Go to Firefox instead.  The Mozilla mail client and the other 
> things of Mozilla, except the browser itself, are not the default 
> applications.

Can epiphany/galeon/$random_browser_using_gecko_engine use firefox
instead?

> * Any application that pulls in scads of libraries that only it uses.  
> Distribution bloat is easily tracable to the Favorite Tools syndrome.  "I 
> like guile, you like scheme, doo-da, doo-da, We need more LISPers in the 
> meme, oh the doo-da day.... "(Going to code all night, going to code all day, 
> bet my money on the K-D-E, oh the doo-da day)  (I'm not going to a second 
> verse featuring clisp and gcl, though....)

You already made your case against gnucash ;-). Still this should be
decided on a case by case basis.

> * Tcl, OTOH, can go.  The ISDN4K stuff has a dependency, but then again why 
> exactly is ISDN4K in CORE?  That's one of the first packages I trim out.

Because there are quite some people who depend on ISDN for Internet
connectivity. Not in the U.S., granted ;-).

> * SELinux.  Yes, I know, this sounds wrong, and I know it is core technology 
> for RHEL, or at least will be at some point.  But when the sample policy 
> package masses 22MB, something is wrong.  How many FC users have SElinux 
> disabled?  If it can be made more compact then by all means include away.  
> But 22MB is too large, IMHO.

To use SELinux effectively, it has to be installed from the start.
Installing it afterwards is -- uhm -- icky, which bites with that we
want as many people as possible to use it.

> Other things to help the installed bloat:
> * i18n resources for OpenOffice.org split into locale-aware packaging.  This 
> is, IMO, one of the serious deficiencies of the kde-redhat repository, where 
> the OOo i18n package is _427_MB, which is absolutely ridiculous.  If I never 
> plan on using Korean or Japanese I don't need them installed.  OTOH, the 
> Korean and Japanese (to use a couple of handy examples) users need those 
> packages. 
> 
> * i18n trimming all around.  Now, this is done for some things already, but 
> each packages should be selected-locales-aware.  That is, after all, why the 
> installer ASKS which languages you want installed.  All packages should honor 
> those choices; however, packagers need to know how to get to those choices 
> and set up the proper locales.

To complement this, after-the-fact de-/installation of languages should
be made much easier than it is now -- changing /etc/sysconfig/i18n and
reinstalling every language-aware package just doesn't cut it.

> Oh, as another benchmark, the kernel itself is the 16th largest package on my 
> system, massing 35MB (!!!!) (A BIG part of that is 
> the /lib/modules/$version/build tree).

The build directory could really be split off into a separate
sub-package so that only people who want to build modules against
running kernels need to install it.

> Now, let me tell you a story of a package that got cut out of the shipping Red 
> Hat Linux because of size limits.  This was an inocuous package; it was a 
> useful package, and, doggone it, it was MY package!  But out it went.  The 
> package was postgresql-test, which is a package of the regression test suite 
> for PostgreSQL. (The whole PostgreSQL set of packages is in a sense MY set of 
> packages, even though Tom Lane is the Official Red Hat Maintainer (I am the 
> PostgreSQL Global Development Group's maintainer, which is confusing since 
> Tom is a member of the PostgreSQL steering committee.  I was maintaining the 
> community package before he started working for Red Hat)).  It was just a few 
> MB, but it did get canned (it has since resurrected, but can once again get 
> canned for that matter, although it might be difficult to have the 
> subpackages from one source RPM split between Core and Extras, assuming 
> PostgreSQL stays in Core).

You have to agree that for most people, gnucash has more use than
postgresql-test ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040725/932b71ee/attachment.sig>