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@xxxxxxxxxx
"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
Attachment:
signature.asc
Description: This is a digitally signed message part
