In article <[EMAIL PROTECTED]>, John Goerzen <[EMAIL PROTECTED]> wrote: >On Tue, Mar 09, 2004 at 09:44:23AM +0000, Miquel van Smoorenburg wrote: >> In article <[EMAIL PROTECTED]>, >> Philippe Strauss <[EMAIL PROTECTED]> wrote: >> >More seriously, my point is: >> >Is there any hope to one day, to adapt debian to the number of packages >> >it bears and split release cycles between a core of 300-500 packages >> >and having the rest of packages evolving at their own pace, following >> >the core? >> >syncing so much package around "release" schedule is becoming >> >unrealistic. I'm waiting testing to become stable for so long. >> >> That would be a godsend. It would work, too. It's happening already: >> a lot of people run woody as "the stable core" and backports.org >> as "the rest", so the idea certainly has merit. > >I think it has some problems, though -- for instance, differences in >versions of libc. If we supported building packages from source better >(which I really think we should), this instantly becomes more practical.
As long as "the core" is stable, you shouldn't need to upgrade it. I did't see any real differences in the glibc features from woody (2.2.5, 2 years old) and sarge, until very recently (that is NPTL support). Just be very conservative on the libraries, that means development libraries too. Core library upgrades aren't needed very often anyway, it's just apps that you want to upgrade more often than every two years. As long as new "the rest" packages are always compiled against the latest "stable core" (and not the latest unstable!) there shouldn't be a problem. Mike.
