Splitting up Core is quite sepperate from there being outside package maintainers. I'm suggesting that Core be split up into different layers of INSTALL AND RUN TIME DEPS, not that the organization of the build change. I'm suggesting a hardcore Core which is very small, contains only what is needed to have a functional, configurable, updateable system. I'm suggesting a Desktop set which provides desktop features, and has deps into Desktop and Core. Etc. I'm suggesting, basically, that the install time grouping be development time groupings, and that their be sub-projects for these different levels, with their own time tables, mailing lists, repos, etc., but a common build environment. I just think it would be more managable. On Tue, 8 Jun 2004 22:58:56 -0400 (EDT), Tom Diehl <tdiehl@xxxxxxxxxxxx> wrote: > > > On Tue, 8 Jun 2004, Crutcher Dunnavant wrote: > > > 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. > > 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. > > > > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Crutcher <crutcher@xxxxxxxxx> www.samedi-studios.com
