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

[Tom Diehl]

On Tue, 8 Jun 2004, Crutcher Dunnavant wrote:

> On Tue, 8 Jun 2004 18:18:54 -0400, Willem Riede <wrrhdev at riede.org> wrote:
> > 
> > 
> > On 2004.06.07 22:18, Tom Diehl wrote:
> > > On Mon, 7 Jun 2004, Willem Riede wrote:
> > > > On 2004.06.07 10:24, Stephen Smoogen wrote:
> > > > > On Sun, 2004-06-06 at 22:33, Steven Pritchard wrote:
> > > > > > On Sun, Jun 06, 2004 at 03:23:41PM -0400, Willem Riede wrote:
> > > > > > > How would that work with respect to upgrades? Haven't we had cases where glibc
> > > > > > > needed to be upgraded and that change affected virtually all applications?
> > > > > > > With a monolithic distribution that is pretty painless, compatible versions
> > > > > > > are available and replace their ancestors.
> > > > > >
> > > > > > This really comes back to a question that came up a week or so ago...
> > > > > > How should anaconda handle third-party installation CDs?  (If the
> > > > > > method is good enough for Fedora Extras, it should be good enough for
> > > > > > any third-party repository.)
> > > > > >
> > > > >
> > > > > 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.
> > > >
> > > > But at that point you have a broken system - not acceptable IMHO.
> > >
> > > Why do you think it is broken? That makes no sense.
> > 
> > Because I am talking about the case where e.g. glibc changes in a way that needs
> > changes in applications to make them work again. Since with a mini-core most of
> > the applications will not be in core, but in extra's, they wouldn't be upgraded
> > when you do the core upgrade, and therefore not work afterwards. QED.
> > 
> > Regards, Willem Riede.
> > 
> 
> Why wouldn't they be upgraded? Why wouldn't I rebuild these apps in
> their repos (Desktop, Devel, Multimedia, Education, Extras, etc.) when
> something they depended on in Core was upgraded? That would be silly
> of me.

While I agree it would be silly Willem might have a valid point. Think about
a set of packages that are currently maintained in core that depend on
glibc for instance. Now break them out of core but obviously leave glibc
in core. What happens when there is some secret security hole in glibc and the
maintainers of the packages that depend on glibc are not Red Hat employees,
and therefore do not have access to the security info ahead of time.
Is it possible that the updated glibc packages are available but due
to nda's etc that go with this type of thing the other packages are not
available until some time later?

Maybe I am streaching tis a bit far but since I am not involved with any of
this I am not sure.