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

Re: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in Fedora Core 3



On May 24, 2004, "Bryan J. Smith" <b j smith ieee org> wrote:

> I mean, is there a reason we need to maintain a 3+ CD set for FC, just
> as to match the "legacy" design of old Red Hat Linux (RHL)?

Here are my favorite reasons:

Downloading an entire distro per machine installed isn't feasible for
a large number of people in the world.  Having a set of CDs that
people can download once, install on a lot of machines, then install
updates plus any additional packages over the Internet works; having
to download the entire distro for every install isn't.

Sure, local mirrors of Extras repositories may help alleviate the
bandwidth, but you have to have a significant number of machines for
this to actually make sense.


Another issue is that Extras packages don't generally work right after
a new Core release is out.  You have to resort to using Extras
repositories of earlier releases until they've installed the new
release themselves, and mass-rebuilt the packages for it.  This takes
time.  Since Fedora Core releases are already short-lived, and having
to wait some time in order to install them makes it even shorter.

And then, there's the issue of testing.  The smaller the core, the
fewer applications you'll get tested as part of the release process.
No matter how competent the extras packagers are, unless they maintain
a rawhide track of their repositories (and I don't think any of the
major repositories do), their packages for a new distro will only
begin getting tested when the new distro goes out.  That means further
instability and poorer user experience.


IMHO, the ideal solution for this problem is to not shrink the core or
split it from extras, but actually create a distro that contains core
and extras CDs, giving the installer the ability to install these
extras.

Sure, people who push for the Extras don't get to maintain fewer
packages, which was one of the main motivations of the Extras model,
but the packages, being in the Core or in Extras, have to be
maintained anyway.

Taking them out of the distro CD set makes them unavailable to a lot
of people, so let's instead start splitting package sets into Extras
CDs: instead of CDs numbered 1 to 4, I envision having CD1 and maybe 2
with a small core, and then separate CDs for Extras.  It is essential,
however, that these Extras CDs be just a packaging artifact, as
opposed to 2nd-class citizens in the distro.  One tricky bit is how to
name the CDs such that people can tell in advance what to download to
be able to install the software they want.  The other is how to rework
the distro compose scripts such that they follow these packaging
guidelines.  None of these should be too hard.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva {redhat com, gcc.gnu.org}
Free Software Evangelist  oliva {lsd ic unicamp br, gnu.org}



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