Re: stable with 2.2.11 (was Re: Stable release management)
On Tue, Aug 24, 1999 at 02:15:45PM +0200, Christian Meder wrote:
> 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).
I'm not saying releasing slink with 2.0.x as default was bad, just that
now 2.2.x has proven itself to be much more stable across more of the sun
archs. Knowing that, it would be a bad move to not make it a 2.2.x
release.
> 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
First off, the 2.1pre does not support unix98 pty's, while that by itself
might not be much of a concern, the fact is it's a 2.1 glibc and _should_
have all of the functions expected in the 2.1 release. There are alreayd
too many issues involved in compiling against 2.1, let's not add a
pre-release with missing, _expected_ functionality. 2.0.105 was great for
a slink release, it got the dist out the door and into the publics hands.
This time we need it done right, with what we have available. Glibc 2.1 is
the better choice...release?/pre-release?, I don't see the argument.
The vfork problem may be non-existant in the 2.1.2. Either way, the libc6
preinst, checks and fails in the cases known to cause problems
(<kernel2.2, <kernel2.2.7&&sun4m). The systems wont be left broken.
> 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 ;-)
You don't understand, fixing the problem will still make it not run on
non-2.2 kernels. This is an issue of system calls that were compiled in as
being available, and the running it on a system without those calls. It
just wont work. You could probably hack it, but the fact is, at run time
the chown call wont work the same on 2.0.x as it does on 2.2.x. If we let
people assume it will, then we break things (lots of programs test
chown()'s usage, and compile based on that finding, if they don't get what
they expect, they break on different kernels in unknown ways).
> > egcs64 is up to date and compiles kernels fine.
>
> Cool. gcse patch applied ? Then let's push it into the updated stable
> release.
Yes, in the latest upload.
> > gcc 2.95.1pre is in the
> > potato archive.
>
> Not an issue for the re-release.
This is probably best, as it has only been in the archive for less than a
week.
> > 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.
Branden? Steve? Probably just needs one when that particular xserver
installs (and can probably cat /proc/fb to make extra sure and check the
uname -r).
> > 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.
I know this, but now we don't have to do that, we have better more stable
options, why force ourselves to use this now, last time we didn't have a
choice. The thing is, people don't have to upgrade their libc in order to
upgrade their packages. They can hold off the old libc, and just upgrade
packages. So in essence they get the stable dist you describe. Remember
that glibc sodeps are still at >=2.0.105.
Ben
Reply to: