On Tue, 8 Jun 2004 18:18:54 -0400, Willem Riede <wrrhdev@xxxxxxxxx> 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. -- Crutcher <crutcher@xxxxxxxxx> www.samedi-studios.com
