Re: stable with 2.2.11 (was Re: Stable release management)
On Mon, Aug 23, 1999 at 04:04:11PM -0400, Ben Collins wrote:
> On Mon, Aug 23, 1999 at 03:37:33PM +0200, Christian Meder wrote:
> > > This is completely untrue. In fact the slink sparc release was with a
> > > 2.2.1 kernel _because_ it was more stable than the 2.0.x kernels for this
> > > architecture.
> >
> > Sorry to say that your comment is only partially true ;-)
> > The 2.2.1 kernel was added to the slink sparc release for two reasons:
> >
> > * sun4u (Ultra) support was only usable with > 2.1.x kernels
> > * 2.0.35 had a slowdown kernel bug on some sparc cpu models which was
> > only fixed in 2.1.x kernels
> >
> > On my Sparcstation10 2.0.35 was a perfectly stable kernel. Steve Dunham
> > pushed 2.2.1 in to support the sun4u architecture and we weren't sure
> > if it would work out well on all sparc cpu's because it was still brand
> > new stuff when we released slink ;-)
>
> Looks like stability reasons to me (atleast in the case of the sun4c slow
> down issue).
>
> Either way, even if 2.0.35 ok on your machine, it does not mean it's not
> more stable across _all_ sun platforms, which IMO, wins by default.
you forget about the time when the decision was made: 2.0.35 was known
to be stable (uptimes of more than 100 days), 2.2.1 was _supposed_ to be
stable but we didn't know it back then.
To cut it short:
To support both 2.0.35 and 2.2.1 for Sparc slink was IMHO the right decision
_at_ the time of the slink release; nowadays we can drop 2.0.x support but
only _after_ the upgrade (we should support upgrading when running a
2.0.35 kernel).
>
> > > In case you want to know, right now I plan on trying to push getting the
> > > 2.1.2 glibc into the sparc/slink re-release simply because the 2.1pre
> > > (2.0.105) is not as stable, and actually compiles binaries that aren't
> > > binary compatible with other sparc distributions.
> >
> > Could you elaborate in which areas 2.0.105 is unstable ? I'd be pretty
> > hesistant to upgrade glibc without some striking arguments (binary
> > compatibility with other distributions is a somewhat weak argument as
> > there's only RedHat in the sparc arena and RH5.2 was based on glibc2.0
> > which is incompatible by design and RH6.0 is glibc2.1 which should be
> > mostly compatible to 2.0.105). Besides we need to test first if there's
> > a working upgrade path for 2.0.35 users when upgrading to glibc2.1.2. Last
> > time I checked a 2.2.x kernel was a prerequiste for upgrading glibc2.1
> > which should be fixed (the upgrade should be possible with a 2.0.35 kernel).
>
> 2.0.105 is a pre-release, for the most part it's imcomplete in certain
> areas, and leaving our dist with it makes us one of those dists who
> release with alpha/beta software as "stable".
I just checked the changelog between 2.0.105 and 2.1 and I really don't
know what you're hinting at if you say 'incomplete'.
Besides you'll run in the vfork sparc problem if you go to glibc2.1
> Anything compiled with this
> version of libc wont run on RH's stock unpatched version of glibc 2.1 (not
> because of RH, but because of certain issues with egcs and chown() blah
> blah blah). Now the version we have in potato of libc and egcs (right now
> gcc2.95) will not only run our old binaries, and run RH's binaries, it
> also compiles binaries that run on the old slink system (99% atleast) but
> also run on RH's sparc glibc 2.1 too. This is a major thing. There are
> companies out there (I know from direct contact) that have held off using
> Debian as their sparc/linux development platform because of this
> incompatibility. I'm sure there are a lot of other non-commercial
> developers that are in the same boat.
So why don't we fix just the chown problem with 2.0.105 and leave it at
that. Using a patched egcs to compile glibc and correcting the chown
problem should result in RH compatible binaries, right ?
Both of these changes are low risk compared to upgrading the whole libc
and as we happen to have a pretty stable sparc slink release I'm hesitant
to risk too much ;-)
>
> > Sparc needs an updated egcs and egcs64 package (important bug fixes,
> > miscompilation of 2.2.x kernels) and a
> > newer kernel (although 2.2.9 should be fine). Additionally I would like to
> > sync the source packages in the update, sparc has got a few .1 packages
> > which can't be build from the corresponding source packages without a
> > patch (the patches weren't included by the maintainers in time for the
> > release). The Xsun24 should be updated (Steve incorporated the relevant
> > patches in the potato package) because the Creator graphics board support
> > is sooooooooo slow in slink.
> > That's my wishlist ;-)
>
> egcs64 is up to date and compiles kernels fine.
Cool. gcse patch applied ? Then let's push it into the updated stable
release.
> gcc 2.95.1pre is in the
> potato archive.
Not an issue for the re-release.
> As far as some of the .1 NMU packages, that will need to
> be scripted out. The wanna-build db reports a surprisingly syncronised
> dist on our part for slink with a few exceptions.
I know ;-)
> Steve and Branden have
> been working together on the X and Creator support (Creator support _will_
> require a fairly new 2.2 kernel according to Steve).
We need a big fat warning in the updated X package.
> As far as the support for 2.0.x support in glibc, that's what got us the
> problem with 2.0.105's binary incompatibility with stock libc's.
> Personally I would not run a 2.0 kernel on a sparc any more because of all
> the problems with libc/syscalls.
You forget again that 2.0.x was all we had at the time of the slink
development. I recommend 2.2.x kernels too, but that doesn't exempt us
from providing a secure upgrade path for 2.0.x users (remember Debian
is well known for providing usuable upgrade paths). RH5.2 Sparc to RH6.0
wasn't that hasslefree.
Greetings,
Christian
--
Christian Meder, email: meder@isr.uni-stuttgart.de
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows,
It sets the sand a-blowing,
And the blackberries a-growing.
(Henry David Thoreau)
Reply to: