Re: debian is too big
In article <[🔎] 20040309182513.GA30252@complete.org>,
John Goerzen <jgoerzen@complete.org> wrote:
>On Tue, Mar 09, 2004 at 09:44:23AM +0000, Miquel van Smoorenburg wrote:
>> In article <[🔎] 000501c4056b$141ab270$0a5ea8c0@LEELOO>,
>> Philippe Strauss <philippe.strauss@practeo.ch> 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.
Reply to: