On Mon, 23 Oct 2000 00:36:14 Gregory Maxwell wrote:
>
> > I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> > 2.96 what is broken.
>
> It compiles. Does it really work fine for all tasks and all people? Who
> knows. It is know that your described configuration is not very well tested.
>
> If 2.96 is broken, I'd appreciate it if you would describe the breakage.
With the kernel, it refuses to compile somehthing (checksum.S) related with
varargs in macros that is perefectly legal reading the info files for gcc.
> RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
> with a 2.2.16-22 which is the richest description that the current framework
> allows. They also ship a source package which contains each patch separate
> from the source.
The '22' there is the package version, not related to the gcc or kernel
version. When RH (or Mandrake) package a thing in an rpm, is thing-2.3.4-1.rpm.
If they discover the left a pair of icons at home, the new package is
thing-2.3.4-2.rpm. If they misplaced an script, new one is thing-2.3.4-3.rpm.
But thing is still 2.3.4. So you could have kernel-2.2.18pre7-1.rpm.
If they discover a patch was badly applied, public kernel-2.2.18pre7-2.rpm.
If they apply NEW patches, from pre 8, it is now kernel-2.2.18pre8-1.rpm.
>
> The unfortunate consequence of the kernel versioning is most users can't
> understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
>
And should not be that way, because 17 usually includes all the patches to
16 that mutate it in -22, and even more.
--
Juan Antonio Magallon Lacarta mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
