On Sat, 2006-05-27 at 10:50 +0300, Mikhail Kolesnik wrote:
Seems me is going to make himself a fool once again...
On Sat, 27 May 2006 01:17:11 +0200 Mark Rosenstand <mark@borkware.net> wrote:
Also, I've been using glibc 2.4 since it was released (shortly before crux 2.2) and have only hit a single problem - details on http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/7195
As for glibc, I'm not to sure what benefits the newer version has, but gcc 4.1 definately have some nice improvements over 4.0.
Hope, these results was mentioned in context of the future development...
Won't it be better to stuck with particular gcc/glibc version during one official crux release life cycle?
Yes, I think these updates are 2.3 material.
Are crux users supposed to be 'bleeding-edgers'?
Not according to the handbook, which states "the latest stable packages" - although for critical core components it makes sense to be a bit more conservative, e.g. leave out x.x.0 versions of the C library and compiler. That said, the reason I'm advocating gcc 4.1 is that we're currently using 4.0. Had we still been at 3.4, it wouldn't be as tempting given the 3.x -> 4.x breakage.
As for me, it also would be great too have official releases less frequently, say one in 14-16 months (and updating non-toolchain stuff more frequently).
Or even better: core could be branched, while opt is a moving target. People could then choose to stick to the release version of core (or a security-fixes-only branch of said release) while those wanting to help make the next release top-notch could follow trunk. Both camps would run the latest and greatest opt ports. This is much similar to the FreeBSD 'src' and 'ports' modules. While pushing toolchain updates 14 months into the future would probably make a relatively stable base for the next ... 14 months, it won't reduce the breakage at that point, which in turn means you'll have to do 14 months worth of head scratching.