Seems to me, that the non-default gcc bundle could go in extras as well...
That is, keep the version that the system was built with and throw the other
Pretty significant savings there as well (when we're trying to loose a CD)
Also, since OOo is default office app. in both KDE and Gnome, and actually
seems to have become quite useful, perhaps abiword, gnumeric, koffice and
friends to go to extras too.
Anyway, just thoughts!
The following is a proposal for modularizing Red Hat's
/etc/rc.d/rc.sysinit script. This proposal solves the problem of having
to patch rc.sysinit and respin the RPM when modifying the rc.sysinit
process (instead, simply add a script to a directory).
It would be nice if rc.sysinit was broken into chunks and organized in
separate files, similar to what was done with init.d. The following
scheme should mesh fairly well with the way /etc/rc.d is already set up
on Red Hat systems, and it also closely (but not exactly) follows
conventions used in Debian and Gentoo systems, as well as others (e.g.
symlinks in an rcS.d directory to init.d/* scripts).
- Each chunk of rc.sysinit would be a file in a directory
"/etc/rc.d/init.d", prefixed by "boot.". So, the "example" section of
rc.sysinit would be "/etc/rc.d/init.d/boot.example"
- a new directory, "/etc/rc.d/rcS.d", would contain symlinks to scripts
in "/etc/rc.d/init.d". These symlinks would start with "S" and then a
two digit number, then the script name, with the numbers ascending in
the order that the scripts should be run. This is similar to what is
done with rcX.d scripts, where "X" is any runlevel.
- The rc.sysinit script itself would remain, and it would be the script
that calls scripts in rc.sysinit.d in the appropriate order. This means
that nothing else in the boot setup would need to change since running
rc.sysinit until completion would still be all that needs to be done.
That mechanism is already in place, obviously.
Given way rc.sysinit is written now, a shift to this scheme is not
exactly straightforward. I tried to write a patch for this during a
limited period of time I had, but I wasn't able to finish as things got
a little more complicated than I expected and having help from the
beginning would be best. Perhaps there are better schemes? Also, having
help from people who know more about the order of operations in
rc.sysinit would be great.
Comments would be appreciated. I would be interested in such a scheme
for the reason at the top of this email, but there are probably more
benefits (why did Debian, Gentoo, etc. do it? Ease of maintenance?).
Linux System Software
Silicon Graphics, Inc. (SGI)
There was a thread a few days ago about the minimum size of fedora and
the number of dependencies that the packages do have today.
Since seems to be too late for FC4, perhaps as a suggestion for FC5,
please consider breaking the packages into smaller pieces so when we
need package X it does not forces us to download a dozen of extra
packages just to conform to it's dependencies.
We can reduce the minimum hw necessary (good news for 3rd world/legacy
hw) and ease admins' lifes (less packages to configure/worry).
What would it take to make ia64 support in Fedora bit more official? I.e.
part of core releases, part of the Extras build process, etc. I might be
interested in taking it on if it's not something huge...
FWIW, I've been using it pretty regularly on an Altix 350 I have here and it's
working pretty well for the most part (at least as well as it does on my
Rahul Sundaram <rahulsundaram(a)yahoo.co.in>:
> --- "Eric S. Raymond" <esr(a)thyrsus.com> wrote:
> > Rahul Sundaram <rahulsundaram(a)yahoo.co.in>:
> > > can you make your explanation available online in
> > the
> > > FUDcon page please and that applies rest of the
> > > people who made presentations but didnt provide
> > them
> > > online too
> > I presume you're talking about a wiki somewhere.
> > Care to give an URL?
> not sure about the wiki part but here
How do you suggest I go about making my explanation available?
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Rahul Sundaram <rahulsundaram(a)yahoo.co.in>:
> can you make your explanation available online in the
> FUDcon page please and that applies rest of the
> people who made presentations but didnt provide them
> online too
I presume you're talking about a wiki somewhere. Care to give an URL?
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>Send fedora-devel-list mailing list submissions to
>To subscribe or unsubscribe via the World Wide Web, visit
>or, via email, send a message with subject or body 'help' to
>You can reach the person managing the list at
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of fedora-devel-list digest..."
> 1. Re: FC4 slimfast slimfest (Eric Warnke)
> 2. Re: FC4 slimfast slimfest (Jesse Keating)
> 3. Re: FC4 slimfast slimfest (Elliot Lee)
> 4. Re: FC4 slimfast slimfest (Ronny Buchmann)
> 5. Re: FC4 slimfast slimfest (Phil Muldoon)
> 6. Re: FC4 slimfast slimfest (Andrew Overholt)
> 7. Re: FC4 slimfast slimfest (Ronny Buchmann)
> 8. Re: FC4 slimfast slimfest (seth vidal)
> 9. Re: FC4 slimfast slimfest (Mail Lists)
> 10. Re: FC4 slimfast slimfest (Alexandre Oliva)
> 11. Re: FC4 slimfast slimfest (Alexandre Oliva)
> 12. Re: FC4 slimfast slimfest (Bill Nottingham)
> 13. Re: FC4 slimfast slimfest (Bill Nottingham)
> 14. Re: FC4 slimfast slimfest (Bill Nottingham)
> 15. Proposal for CD count in FC4 (Jesse Keating)
> 16. Re: FC4 slimfast slimfest (Alexandre Oliva)
> 17. Re: FC4 slimfast slimfest (Alan Cox)
> 18. Re: FC4 slimfast slimfest (Chris Adams)
> 19. Re: FC4 slimfast slimfest (Matthias Saou)
>Date: Mon, 21 Feb 2005 16:34:45 -0500
>From: Eric Warnke <eric(a)snowmoon.com>
>Subject: Re: FC4 slimfast slimfest
>To: Development discussions related to Fedora Core
>Content-Type: text/plain; charset="iso-8859-1"
>I know this will be an unpopular suggestion, but 300MB is a lot to
>loose. So I'm just throwing this out there.....
>KDE by my estimates is 350mb, move it into extras.
>Elliot Lee wrote:
>>Here's a heads up that we need to get rid of about 300M of packages to
>>make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
I agree that a cd two install would be good and have packages available
from online. However I think there does need to be an option for a full
cd set download. I do many installs that are on machines with no
internet connection and also do jobs onsite where there is only a dialup
option. Many people I speak to say that they would have tried suse
except for the need to download packages from an ftp server on install
has stopped this as the install was a nightmare.
If the number of cd's is getting too much - why not refer onto dvd
installs as most machines these days have them and this would then
reduce the amount of disks to two and provide the cd download for people
who required it.
Please feel free to comment.
The topic of Wubi input for iiimf has been discussed previously about
a year ago, but at that time, from what I understood by perusing
archives, there were licensing issues. Is there any movement on this
front since then? Gimlet has greatly improved between FC2 and FC3, but
Chinese input is still limited to Cangjie (Traditional, very obscure
for novices), or Pinyin, which is tied to the Northern Mandarin
dialect. While Pinyin is great for newbies like me, it also ulimately
hurtsss usss, because of its ties to one dialect and because it's
impossible to type in unfamiliar characters -- must know how it's
pronounced, which is more often than not... difficult... to divine
from the character itself.
The Wubi input method solves the latter problem, and is increasingly
popular for Hanzi/Kanji input. I understand it's part of SCIM, but
it's unclear to me how SCIM ties to IIIMF. Can anyone shed some light
on the status of Wubi input in Fedora?
Wow, 7 digests were spawned from today's back and
forth on this topic. About two digests from the
latest ones people made the following suggestion and I
wanted to ditto:
At the rate I've noticed, from finish of FCX to finish
of FCX+1 is about 8 months. (Give or take a month)
So why not let FC4 be 5 CDs. When FC5 comes out at
the end of the year, we will have anaconda installing
from repos anyway, and we can trim down all the way to
1 or 2 CDs.
Perhaps I'm the atypical user, but going through all
of the packages in yum and trying to figure out what
to install from the "extras" is a lot more of a hassle
than downloading another iso. Just leave it going
over night...does anyone pay by the hour anymore?
(And don't use AOL cuz it may kick you off)
Finally, about FC3 not being in magazines...that is a
false statement. Linux Format Magazine recently
included FC3 in the DVD edition of their magazine. So
while the issue of trimming down Fedora may be moot
after this distro (with the anaconda fix/update/hack),
I don't think having just 300mb (not even half a 700mb
cd) extra is a big deal.
I think that's been lost over all of these emails -
it's not really an extra CD it's an extra half-cd. So
one wait's 1.5 times as long as they do now, no
I really think it would save a lot of hassle.
Vote with me 5 CDs in FC4 and 2 CDs in FC5
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> From: Michael A. Peters
> Sent: Monday, February 21, 2005 10:10 PM
> To: fedora-devel-list(a)redhat.com
> Subject: Re: FC4 slimfast slimfest
> On 02/21/2005 06:11:00 PM, Chris Adams wrote:
> > I think you are overestimating the importance of Java to the average
> > user.
> I also would prefer JPackage handle Java.
> Here's why - JPackage is very good at making things available on many
> distributions. I've already sent e-mails to several developers of Java
> apps suggesting they package their product in an rpm with the
> dependencies satisfied by what is in JPackage, so that Linux users can
> simply add the JPackage repository, and then yum localinstall the rpm
> and whatever is needed will just be grabbed. Some developers e-mailed
> me saying they had not heard of JPackage but they liked what they saw.
> In many cases this work for several distributions with just a single
> rpm from the vendor, but if Fedora deviates from JPackage, then
> instructions for Fedora would have to be different than instructions
> for other distro's.
> I'm not a Java developer, I honestly don't like GUI Java apps in most
> cases (it's the interface - not pretty) though I do like a few because
> they are very good at what they do.
> As far as packaging Java, JPackage is very good at what it does - I
> have never before had such an easy time getting Java applications to
> just work.
> I would rather see support (and I do see it) of RH and Fedora for the
> JPackage project, and let JPackage handle everything Java. Maybe ship
> JVM but not until it can do applets.
> Ship with a jpackage.org repo file installed that a user just needs to
> enable to use.
> Michael A. Peters
+1. The added bonus for this option is that the maintenance of the
packages themselves is left to the community rather than to an already
overworked Redhat staff which is maintaining 2 distros (FC and RHEL).