[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: PROPOSAL: Core size reduction "bug day"
- From: Lamar Owen <lowen pari edu>
- To: Development discussions related to Fedora Core <fedora-devel-list redhat com>
- Subject: Re: PROPOSAL: Core size reduction "bug day"
- Date: Sat, 24 Jul 2004 21:17:42 -0400
On Fri, 2004-07-23 at 20:28, David Nielsen wrote:
> As everyone probably knows a few days ago a suggestion was brought up
> that we start moving none essential stuff like KDE, XFce and a lot of
> the other duplication into Extras in order to reduce the size of Core.
KDE is essential.
There are other candidates, one of which I mentioned to Michael Tiemann the
other day. These are but a few suggestions, based upon sorting by size and
running test removals under Synaptic. All sizes quoted below are installed
sizes as reported by Synaptic. It appears to me that Synaptic underreports
sizes by a significant margin, though.
* octave (do you know anyone who uses it?) If anything, it should be replaced
with R, which is larger, unfortunately. I haven't had octave installed in a
very long time. Definite extras material. This one I mentioned to Michael
the other day.
* 4Suite (system-config-bind and system-config-httpd are dependants; is there
another package that can provide the functionality that those two
configurators prequire? Does anyone use 4Suite outside these two packages?)
* Gnucash (72MB). Extras, not Core. I have this one installed, but it still
is not Core functionality.
* kdeedu (46MB) Extras, not Core. kdeedu-devel too.
* MySQL. (:-P) Red Hat shipped PostgreSQL first, but any RDBMS might easily
be considered Extras material. Along goes tora.
* koffice. While I think KDE proper should be in (and not necessarily all KDE
modules) Core, OOo is pretty much the standard office, even though I
personally use koffice much more heavily, as it is not as bloated. But
koffice not being the default it might should be Extras material.
* 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?
* The double compilers. If we're going gcc3.4, let's get there and lose the
other versions. The second compiler set costs lots of space. Looking at
RawHide I see that it is just as bad, since we now have real gcc-3.4.1, but
we duplicate to gcc35-3.5.0. The source RPM is 25MB; I can imagine how
bloated the binaries are... :-(
* 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
* Pick one of: vim, emacs, xemacs to toss. Preferably toss xemacs. Talk
about redundancy: we have two full-bore EMACS! This is a worse problem than
two different and competing desktops! Can't check the sizes of them, though,
since I don't have either *macs installed...
* 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.
* Mozilla. Go to Firefox instead. The Mozilla mail client and the other
things of Mozilla, except the browser itself, are not the default
* 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....)
(In case you're wondering, I'm tracking bloat using the new Synaptic (0.52),
which allows sorting by SIZE within categories, or across the whole
installation! Then you can track dependencies and dependants easily.)
* The whole Java infrastructure is pretty bloated, and is apparently why FC2
is *blessed* with a second compiler. But we then still have the 3.3 libgcj,
which only has gcc-java and libgcj-devel as dependants! Those three
packages take 13+22+4=39MB. And that's the UNUSED gcj! The used libgcj is
larger, and has large dependants. Actually, lessee... of the things
depending upon libgcj34 that I have installed, if I select to remove
libgcj34, it tells me 81.7MB will be freed, which is not as large as I
* While the Python subsystem is large, it is also core to all things
system-config and must stay.
* 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. I
do, however, keep tcl, but it's a custom tcl to run OpenACS/AOLserver, which
requires a multithreaded tcl, which AFAIK is not the default build. And the
FC tcl is usually pretty far behind the curve. A pity, since tcl is quite
small, only weighing in at a couple of MB.
* Tetex dependants. While this is fairly core stuff, its dependants mass over
a hundred MB. (Synaptic tells me 113MB). Is DocBook Core material?
Possibly, but there is lots of stuff that could be looked at.
* 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.
* FWIW, the kdelibs are the largest single library package outside of the core
glibc stuff (that I have installed, at least), weighing in at 35M. I wonder
how much of that is i18n? FWIW, if I select to remove qt and all its
dependants, 733M is selected. But I have much more installed than the
regular KDE. I can't check GNOME the same way, since I don't have GNOME
installed (there are a few things that depend upon gtk that I do have
installed, hmmm...in my NON-GNOME installation it marks 616MB of packages to
be removed if GTK2 is removed. I wonder how much more if I actually had a
usable GNOME installed?) Maybe gtk2 should go to extras? (:-), just
kidding, it's too core for that. GNOME, OTOH....)
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
* 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.
* Trimming down of the printer kluge. Yes, kluge. How many hundred megabytes
does the printing stack take these days? Well, lessee, you have Omni (55MB),
Foomatic (31MB), ghostscript , etc. Lots and lots of bloat here, not
counting CUPS proper. At least we finally rid ourselves of the other
printing subsystem, lprNG.
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). That means that there are fifteen
packages on my NON-GNOME system that are over 35MB in size, with
OpenOffice.org topping the scale with no close competitors. This is wrong.
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).
That is just the tip of the iceberg. There is significant bit-rot in the
distribution as a whole. There are lots of things that can be trimmed. The
list above is about an hour's worth of looking.
On the point about Extras itself: I think making fedora.us the 'de facto'
Extras is the wrong thing to do. Nothing wrong with fedora.us; the problem
is that Extras needs to really be spun out of Red Hat, IMO, so that it will
have a similitude of being official. I personally much prefer some of the
other repositories over fedora.us due to the packages that are there. Some
packages' quality is not so good, unfortunately. None of the different
repositories really cooperate well; I have to be careful mixing and matching
them due to the many differing intersections. But with Synaptic things are
very easy to configure; very easy to see what you are doing, and very easy to
back out if you decide that you do not want to do that.
I think the various repository maintainers need to see once again if they can
cooperate a little better.
Incidentally, while I prefer using the kde-redhat KDE packages, they do come
with their problems. First, they are very invasive with your system,
insisting upon your using their OpenOffice.org, their gtk2, and others. You
get kde-redhat on your box, and you get lots more than just KDE installed.
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
[Date Prev][Date Next] [Thread Prev][Thread Next]