[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Making Fedora Core CD #1 Standalone -- Now you're seeing it my way!

[ I think at this point I've spewed enough vapor, so it's time for me to
go off and do something.  I really appreciate *EVERYONE'S*! input on
this.  I'm going to try to have a "nailed down" comps.xml by the
weekend, and identify some of the "BS dependencies" that should be
removed (if any) on various, basic packages. ]

Chris Chabot wrote:  
> This is indeed a big can of worms. To further complicate the matter,
> you always need to keep the upgrade path in mind to. If someone is
> running redhat 8,9, fedora core 1 or 2, they should be able to
> download the install cd's and upgrade their existing system.

I think some people are missing the fact that I _do_ recognize that. 
And that's why I'm advocating that the full "Core" _not_ be touched.

This new sub-Core would be explicit.  Ideally it would be Core CD #1.

> This means a whole lot of packages _have_ to be included to provide
> compat-XYZ or newer versions of the already installed packages. This
> kind of means that 90% of the existing packages are automaticly tied
> in on the install cd's.

Right.  I don't disagree with that.

> So with that in mind, what profit can still be gained by re-ordering
> packages around on cd's, and making minimal install cd's?
> IMHO you could make the first cd a "Basic but relatively complete"
> install cd, which includes all basic apps, web browsers, basic
> services and server apps, yum, system-config-packages, etc; Which you
> could use to install a new functional and working Workstation, or
> Server installation.

I think that was what I was saying.
But maybe I wasn't saying it as clearly?
My apologies ;-).

> The other (3) cd's would include all the other packages that are
> currently in fedora core 2, and should be listed and described in the
> comps / rpmdb-fedora packages.
> Then if you do a clean install it would only use the first CD to do
> the basic install, run thru first-boot, and allow people to add
> additional packages from either the 3 extra's cd's (it would know
> where they are and ask for the correct cd by looking that up in the
> comps / rpmdb-fedora lists), or offer the option to download them from
> a selected mirror.
> However if you do an upgrade using the first cd, it can use the
> knowledge of what packages are on what cd's to include those in the
> upgrade, and do a clean and sound upgrade (asking for those cd's as it
> does now).
> As far as i can think off thats the only way to satisfy the upgrade
> cycle dependency, while allowing for a 1 core cd install.

Now you're seeing it my way!
Thank you for re-iterating it in another way.
Maybe now others will see it as you do.

> Ofcource then the question becomes "What packages do we include on the
> core cd". To be able to play around with that question i've written a
> little tool in PHP which i've posted in a seperate email (Subject: A
> usefull tool (Was: Making Fedora Core CD #1 Standalone)).

Right, and I'm going to start play with it.

> You would be supprised at how much you can still include on the first
> CD.. With that tool you can show that all this paranoia about "Don't
> include any, *0* apps on the core CD" is being overly zealous..

Well, I'm anal.  I'm thinking of the company that has its own, internal
Apt repository.  So it's easy to fetch what you need for different
systems.  Eventually the company should write its own comps.xml, but
this "Quark" gives them a "nice base."

Eventually I'd like to see the "Quark" weed out a lot of stupid,
unnecesary dependencies in "Core."  But that's a future ideal.

> Your able to fit quite a large collection of workstation and server
> packages on one CD.. The mix that i came up with playing with the
> dep-tree tool is:
> ./dep-tree.php -d firstboot system-config-packages mozilla yum rpm
> mdadm cups vixie-cron httpd samba jfsutils php perl usbutils
> isdn4k-utils irda-utils metacity gnome-desktop gnome-session
> gnome-panel compat-db compat-libstdc++ compat-glibc openssh
> openssh-server openssh-clients openldap samba screen magicdev
> openmotif xmms gedit lm_sensors ntp gnome-utils autofs setserial nmap
> mgetty stunnel curl eject nautilus-cd-burner nautilus-media lsof wget
> telnet ftp gnome-applets gftp openoffice.org gimp gaim links mkinitrd
> mktemp ttmkfdir mkbootdisk xpdf eog gcc autoconf automake15
> autoconf213 automake automake14 make
> Number of packages: 457
> Total size installed: 1557 Mb
> Total packaged size: 498 Mb
> So this includes (i think) all the basic packages for a working linux
> instalation, qt/gnome/kde/motif compatiblity, mozilla, gimp, gaim,
> openoffice and lots of other workstation apps, and all required basic
> server apps (webserver, openssh, telnet, ftp, yum, nmap, screen, wget,
> links etc)

I'd go the other way.  No apps.  Why?  Because in short order, it will
bloat to more than 1 CD.  The idea here is to make it as small as
possible.  Even if its only 300MB or smaller.

Someone can _always_ "fill" the official "Core" CD #1 with more -- but
it all starts with the "Quark" comps.xml _first_, as the "base."  We
need more than the 90MB one (although that's not a bad start).

BTW, does that list include Kerberos?  I probably need to find out by
using RPM-Analyzer.

> The nice thing of this is that the first CD can then offer 4 install modes:
> - Basic Workstation
> - Basic Server
> - Both server and workstation software
> - Minimal instalation (90 or so megs, already included in FC1/2)
> [x] checkbox Include development packages and tools

I  see little reason to include development.  They can be fetched via Apt/Yam.
For those that can't, Quark is not for them.  They should install the full
"Core" instead (possibly from 3rd party DVD with Extras added).

> While still offering a fully functional end result, and including all
> *-devel packages and compilers so the system is self-building and
> allows you to compile kernels, source rpm's or tarbals (imho it would
> go against the spirit of *nix / open source to have a system that
> could not compile software or it's self)

But at what point do you start not including stuff?  I say devel is out
for "Quark."  You have Apt/Yam to fetch them anytime you need.

> Then if they want all KDE apps, more server software, a slow of perl-*
> packages, databases, then the extra 3 cd's come into play (and/or
> external repositories)

Here's what I think should be in "Quark" (or whatever it is called):

- Everything in "Minimal Install" (90MB)
This is a suppport consideration

- All client network services for basic X/GNOME functionality
- All client probing/hardware support
Everything from DHCP to Mozilla, and the GTK+/GNOME to run it
This includes Fonts (which can quickly be a size issue)

- All directory service, authentication, crypto clients/services
- All network client/services having to do with file
Because if you can't connect to any network setup, you can't fetch

And that's all.  No extra GNOME applets or goodies.  No bitmaps other
than maybe the Fedora one.  No frills.  Those can be apt-get'ted.

In an enterprise environment, I'd rather have a "base" install like
Quark on a CD, and then run a script that does an "apt-get" of
everything else needed.  But that's just me.

Bryan J. Smith, E.I. -- b j smith ieee org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]