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?) (24MB) * 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 easily found. * 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 applications. * 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 thought. * 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 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. * 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. Very 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. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
