mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
To: rhw@MemAlpha.CX (Riley Williams)
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Improved version reporting
Date: Fri, 23 Mar 2001 03:33:44 -0500 (EST)	[thread overview]
Message-ID: <200103230833.f2N8XiR141134@saturn.cs.uml.edu> (raw)
In-Reply-To: <Pine.LNX.4.30.0103190846590.21272-100000@infradead.org> from "Riley Williams" at Mar 19, 2001 09:15:37 AM

Riley Williams writes:
> Hi Albert.

>>>> The rule should be like this:
>>>>
>>>>	List the lowest version number required to get
>>>>	2.2.xx-level features while running a 2.4.xx kernel.

>>> Replace that "a 2.2.xx" with "my current" and remove all
>>> restrictions on what the current kernel is, and that becomes
>>> an important question.
>>
>> No, not "my current" but "the previous stable". I say "2.2.xx"
>> because that is the previous stable kernel.
>
> Again, saying either "2.2.xx" or "the previous stable" is meaningless.
> Saying "The 2.2 kernel series" might have some meaning if it was not
> for the fact that the requirements differ for different members of
> that (or any other) kernel series.

Oh please. List whatever the hell is needed for an upgrade from any
of 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, ..., 2.2.255 of course.
Also include previous 2.4.xx kernels, in case some bastard decided to
break stuff within a stable kernel series... like PPP for example.

> On Saturday night, I had the pleasure of upgrading a system from the
> 2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14
> kernel to the 2.4.2 one. Although the target kernel version was the
> same, several subsystems needed upgrading on the former that did NOT
> need upgrading on the latter, and that was just to compile the thing!

So what? Your point is??? Obviously one system was partly upgraded.

> According to you, both of these upgrades would have required EXACTLY
> THE SAME upgrades to be made, but that isn't the case.

I never claimed that.

>> If you upgrade from 2.0.xx, you should read the 2.2.xx changes file.
> 
> Fairy Nuff.
> 
> However, your argument still fails, simply because of its reliance on
> the assumption that an entire kernel series has static requirements
> when such just isn't the case.

There is no such assumption.

If 2.2.4 needs foo-1.7 while 2.2.5 and 2.4.4 need foo-1.8, then
foo gets listed. If 2.1.99 needs bar-0.6 while 2.2.0 and 2.4.4
need bar 0.7, then there is no need to list bar. Never mind that
both foo and bar are up to version 666, since that isn't needed.

>> The important thing is to avoid version number inflation. I don't
>> even bother reading the changes file, because I know it is bogus.
>> Nearly all of my old software works great with a 2.4.xx kernel.
>
> The fact that you said "Nearly all" shows that your argument is false,
> since your argument has been that NO software needs upgrading.
>
> Can I suggest that you re-read my previous missive, and actually look
> at the points raised. If you do, we might just get a sensible
> discussion on this subject...

Try it yourself, w/o alcohol. I didn't argue "NO software...".

> Incidentally, your argument to date has assumed that everybody always
> installs every single kernel version. In my opinion, that is a very
> dangerous assumption to make.

Nope. Most people go from one stable series to the next, often skipping
the first and last few revisions. (2.2.6, 2.2.9, 2.2.17, 2.4.3, 2.4.8...)

> A more responsible assumption would be
> that the person wishing to upgrade to the version in this particular
> kernel source tree has a random system installed, and wishes to know:

That random system should be capable of working with at least
one kernel from the previous stable series.

>  1. What is the absolute minimum upgrades required to compile the
>     kernel in the source tree I have just downloaded?
> 
>  2. What is the absolute minimum upgrades required to install the
>     kernel in the source tree I have just downloaded and compiled?
> 
>  3. What is the absolute minimum upgrades required to enable me
>     to run the kernel I have just compiled from this source tree,
>     assuming that I wish to retain the use of the shell scripts
>     that I developed under my previous kernel?
> 
>  4. What other upgrades are recommended for reasons of system
>     security or stability?

Good, assuming "reasons of system security or stability" relates
to problems that a kernel upgrade might cause.

>  5. What further upgrades are required to enable me to make use
>     of the advertised new facilities in this kernel?

This is noise. Such upgrades are not required.

>  6. What additional subsystems could be upgraded if desired?

This is worse noise: "...and The GIMP is now at version..."

>  7. I note that some upgrades are only required if certain of the
>     subsystems are installed. Which upgrades are these, and which
>     subsystems are they dependant on?

This is getting too fancy.

  reply	other threads:[~2001-03-23  8:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-15  9:52 Andries.Brouwer
2001-03-15 11:05 ` Rogier Wolff
2001-03-17  4:35 ` Albert D. Cahalan
2001-03-17 17:51   ` Riley Williams
2001-03-19  6:50     ` Albert D. Cahalan
2001-03-19  9:15       ` Riley Williams
2001-03-23  8:33         ` Albert D. Cahalan [this message]
2001-03-23  9:42           ` Riley Williams
  -- strict thread matches above, loose matches on Subject: below --
2001-03-17 10:20 Andries.Brouwer
2001-03-17  1:07 Andries.Brouwer
2001-03-17 17:17 ` Riley Williams
2001-03-16 12:45 Andries.Brouwer
2001-03-16 13:30 ` Nick Holloway
2001-03-16 23:28 ` Riley Williams
2001-03-14 19:29 Andries.Brouwer
2001-03-14 23:39 ` Russell King
2001-03-16 10:54 ` Riley Williams
2001-03-14 16:51 Andries.Brouwer
2001-03-14 16:01 Andries.Brouwer
2001-03-14 16:26 ` Alexander Viro
2001-03-15  4:12   ` Albert D. Cahalan
2001-03-14 16:36 ` Henning P. Schmiedehausen
2001-03-14 17:28 ` Riley Williams
     [not found] <11a40b11caeb.11caeb11a40b@nosc.mil>
2001-03-14 10:39 ` Riley Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200103230833.f2N8XiR141134@saturn.cs.uml.edu \
    --to=acahalan@cs.uml.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rhw@MemAlpha.CX \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®