Shrinking/splitting up core Was: Why are there only i686 and i586 Version of glibc...

[Crutcher Dunnavant]

I don't think that this is really that much of a problem. As I see it,
Anaconda would be designed with the assumption that there was only one
distro, the Everything distro, which would include all of the slices.
This way, micro distro installers could be done with a subset, and
anaconda would be fine.

The difference would come on the upgrade path.

Core would be a repo which only had dependancys in Core.
Desktop would be a repo which only had deps in Core and Desktop.
Development would be a repo which only had deps in Core, Desktop, and
Development.
Education (maybe?) would be a repo which only had deps in Core,
Desktop, and Education.
Extra would be a repo which only had deps in Core, Desktop,
Development, and Extra.

Note, these would be install-reqs, not build reqs.

On Mon, 7 Jun 2004 10:39:18 -0400, Jeff Spaleta <jspaleta at gmail.com> wrote:
> 
> On Mon, 07 Jun 2004 08:24:11 -0600, Stephen Smoogen <smoogen at lanl.gov> wrote:
> > I dont think Anaconda is meant to look at anything beyond the bare
> > installation Cd's the rest should be done with first-boot. Maybe first
> > boot should have a yum configuration section where you can enter the yum
> > places you want to to point ot.
> 
> If anaconda only handled installs...and not upgrades this makes sense.
> The real problem comes with how to do media based upgrades cleanly in
> a Core/Extras/Alternatives world.  And if people are serious about
> making Core smaller, and moving things into Extras it makes it that
> much more difficult to rationalize the idea that "most" people won't
> be using extras on their systems.
> The reality is...IF Core shrinks having a media based upgrade path
> that works with Extras media as well as Core is going to be more
> important. If anaconda can be made to cleanly deal with Core/Extras
> upgrade paths(at a minimum...forget for a second Alternatives and 3rd
> parties) then anaconda should just lose upgrade ability completely and
> we should deem another solution as the upgrade path. Moving
> forward..in a smaller Core scenario dealing with Extras during
> upgrades cleanly is something a expect a lot of the unwashed userbase
> are going to need.
> 
> -jef
> 
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 




-- 
Crutcher <crutcher at gmail.com>
www.samedi-studios.com