Re: [PATCH] Improved version reporting
Hi Albert. Since you appear to be determined to ignore reason and stick to your misguided guns I'll leave you to destroy all the good work that has gone into the Linux kernel's documentation and make it something even Bill Gates would be proud of. However, I'll stick to documentation that actually tells people what they need to know whilst you do so. Best wishes from Riley. * On Fri, 23 Mar 2001, Albert D. Cahalan wrote: > 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 add
Re: [PATCH] Improved version reporting
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
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. >> That's a meaningless definition, and can only be taken as such. What >> use would such a list be to somebody wishing (like I recently was) to >> upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 >> kernel instead? > ... >>> Basically I ask: would existing scripts for a 2.2.xx kernel >>> break? If the old mount can still do what it used to do, then >>> "mount" need not be listed at all. >> 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. 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! According to you, both of these upgrades would have required EXACTLY THE SAME upgrades to be made, but that isn't the case. > 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. > 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... 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. 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: 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? 5. What further upgrades are required to enable me to make use of the advertised new facilities in this kernel? 6. What additional subsystems could be upgraded if desired? 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? Personally, I'd be quite willing to work on a system to document the requirements and classifying each requirement according to the above system. However, as a pre-requisite, I would need agreement that such was (a) worth doing, and (b) of interest to the kernel developers. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Riley Williams writes: >> 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. > > That's a meaningless definition, and can only be taken as such. What > use would such a list be to somebody wishing (like I recently was) to > upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 > kernel instead? ... >> Basically I ask: would existing scripts for a 2.2.xx kernel >> break? If the old mount can still do what it used to do, then >> "mount" need not be listed at all. > > 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. If you upgrade from 2.0.xx, you should read the 2.2.xx changes file. 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Albert. >> +o Mount # 2.10e# mount --version > Concerning mount: (i) the version mentioned is too old, >>> Exactly why? Mere missing features don't make for a required >>> upgrade. Version number inflation should be resisted. >> These days you can mount several filesystems at the same mount >> point. The old mount does not understand this at all. Recent >> versions of mount act better in this respect, even though it is >> still easy to confuse them. > 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. That's a meaningless definition, and can only be taken as such. What use would such a list be to somebody wishing (like I recently was) to upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 kernel instead? The ONLY kernel version that any list can be meaningful for is that of the kernel source tree it is a member of, and that leads to the following definition for the versions to be included in such a list: List the lowest version number required to compile this kernel, and to allow the resulting kernel to be used as the heart of a running system. Basically, required upgrades can fall into any of the following categories, and need to be dealt with accordingly: 1. Development tools used to compile and/or link the kernel. 2. System libraries needed to run these development tools: 3. System tools that interact intimately with the kernel. If the kernel interface changes in an incompatible way, these will also need to be updated. 4. System tools that analyse kernel-supplied information and advise the user of the results. 5. Other tools that are dependant on kernel version. 6. Other tools that have been upgraded. My opinion is that only tools that fall in category (6) should be omitted from the list. > Remember what the purpose of the table is. It is a list of > REQUIRED upgrades. Failure to upgrade should result in a broken > system. So pppd must be listed, since somebody changed the > kernel API for 2.4.1. > If I run the mount command from Red Hat 6.2, using it as > intended for a 2.2.xx kernel, doesn't everything work? There > won't be any multi-mount confusion because 2.2.xx can't do that > anyway. There isn't any problem with NFSv3 either, since 2.2.xx > lacks NFSv3. Whilst that's a good question, it misses the whole point of such a list. Can I replace it with a more realistic one: If I take a random Linux-based system and boot it using the kernel I've just compiled using this kernel source tree, will it work? If not, what is the minimum that I need to upgrade to make it work? Remember, there's absolutely NOTHING in ANY of the kernel source trees that depends on what a particular user is running on their system before they get that source tree. > Basically I ask: would existing scripts for a 2.2.xx kernel > break? If the old mount can still do what it used to do, then > "mount" need not be listed at all. 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. After all, if I take the network print server I'm running with a 2.0.19 kernel and drop a 2.4.2 kernel in, will it work without any other changes? Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
>> {Shrug} Thinking isn't sufficient - check your facts.
> Poor Riley,
>
> Probably I should not answer, I think you know all the facts
> already. But just to be sure:
> (i) There are two different packages, kbd and a forked version,
> console-tools. Both contain roughly the same programs. In your
> earlier mails you seemed aware of that, but now you report that
> the console-tools version of loadkeys does not want to print a
> kbd version. No surprise there.
You make claims for me there that I've never made, so can I suggest
you get your facts right this time. For reference:
1. My claim was NOT that the loadkeys from console-tools does
not print a kbd version, as you claim in the comment quoted
above. I claimed that it doesn't print ANY version, including
one for loadkeys itself.
2. YOUR claim was that the loadkeys command ALWAYS displays the
version number, so the command in ver_linux is thus always
guaranteed to produce a version number. MY claim was that
at least one loadkeys command fails to do so, and thus that
one can't expect it to do so.
Thank you for confirming that your claim was false.
> (ii) I am the maintainer of both mount and util-linux.
> If I say that there exists no more recent version of mount
> than the one found in util-linux, you can believe me.
Neither of us has claimed otherwise, nor have we been disputing that.
YOUR claim was that all systems always have the same version of mount
and util-linux installed, even when they are from different packages.
MY claim was that no such guarantee can be given, as it's possible for
somebody to upgrade either without upgrading the other when they are
supplied separately.
Again, thank you for confirming that your claimwas false.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
> If the old mount can still do what it used to do, > then "mount" need not be listed at all. Well, I started saying that the mount line should be deleted, so we somewhat agree. > If I run the mount command from Red Hat 6.2, using it > as intended for a 2.2.xx kernel, doesn't everything work? Roughly, yes. (In other words: no.) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Andries.Brouwer writes: >> From: "Albert D. Cahalan" <[EMAIL PROTECTED]> >>> On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: > +o Console Tools # 0.3.3# loadkeys -V > +o Mount # 2.10e# mount --version Concerning mount: (i) the version mentioned is too old, >> >> Exactly why? Mere missing features don't make for a required >> upgrade. Version number inflation should be resisted. ... > These days you can mount several filesystems at the same mount point. > The old mount does not understand this at all. > Recent versions of mount act better in this respect, > even though it is still easy to confuse them. 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. Remember what the purpose of the table is. It is a list of REQUIRED upgrades. Failure to upgrade should result in a broken system. So pppd must be listed, since somebody changed the kernel API for 2.4.1. If I run the mount command from Red Hat 6.2, using it as intended for a 2.2.xx kernel, doesn't everything work? There won't be any multi-mount confusion because 2.2.xx can't do that anyway. There isn't any problem with NFSv3 either, since 2.2.xx lacks NFSv3. Basically I ask: would existing scripts for a 2.2.xx kernel break? If the old mount can still do what it used to do, then "mount" need not be listed at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
> {Shrug} Thinking isn't sufficient - check your facts.
Poor Riley,
Probably I should not answer, I think you know all the facts already.
But just to be sure:
(i) There are two different packages, kbd and a forked version,
console-tools. Both contain roughly the same programs.
In your earlier mails you seemed aware of that, but now you report
that the console-tools version of loadkeys does not want to
print a kbd version. No surprise there.
(ii) I am the maintainer of both mount and util-linux.
If I say that there exists no more recent version of mount
than the one found in util-linux, you can believe me.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
> Neither am I - but, according to comments from RedHat a while back,
> they repackage mount separately because they provide a NEWER version
> of mount than is in the util-linux package. This will ALSO result in
> `mount --version` giving the wrong answer...
> There is no newer version.
Why do RedHat claim there is then?
> In ancient times I came with frequent releases of mount, at a time
> when util-linux was released very infrequently. These years mount
> is part of util-linux, and util-linux is released frequently.
{Shrug} Persuade RedHat of that, not me - they're the ones who release
it separately. Taken directly from RedHat's FTP site, I note that Red
Hat 6.2 includes RPM's for both mount-2.10f-1.i386.rpm and
util-linux-2.10f-7.i386.rpm which, whilst different releases of the
same version, is sufficient to prove your argument false. I can't get
into their 7.0 tree atm to check due to network congestion, so can't
comment on that...
> Unless one can guarantee that the util-linux and mount packages are
> the SAME version, mount can't be guaranteed to report the version of
> the util-linux package installed. RedHat provide a NEWER version of
> mount to util-linux so that guarantee doesnae exist.
> I do not think they do.
{Shrug} Thinking isn't sufficient - check your facts.
> > You are mistaken, as is proved by the reports that contain a kbd
> > line: a grep on linux-kernel for this Februari shows people with
> > Kbd 0.96, 0.99 and 1.02.
>
> {Shrug} Please explain why I was unable to get ver_linux to report a
> When other people can and you cannot, why should I explain your failure?
> Let me just check. A version from 1993:
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 0.81
>
> A version from 2001:
>
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 1.06
> Maybe nothing has changed here the past eight years. It just works.
> Perhaps you tried some modified version.
I tried the version that came as part of Red Hat 6.2 as installed
unmodified on the system I'm using. According to the rpm command, I
see...
Q> $ rpm -qf `which loadkeys`
Q> console-tools-19990829-10
Q> $
I've now tried that on FOUR different systems running Red Hat 6.2, the
last of them a fresh install direct from genuine RH 6.2 CD's with NO
changes since, and all four report the same and do exactly the same to
the command in ver_linux so I have to assume that the command in
ver_linux is UNABLE to determine a version number with this release of
Linux.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
[EMAIL PROTECTED] writes:
> From: Riley Williams <[EMAIL PROTECTED]>
> {Shrug} Please explain why I was unable to get ver_linux to report a
>
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 1.06
>
> Maybe nothing has changed here the past eight years. It just works.
> Perhaps you tried some modified version.
Debian 2.2 has loadkeys from a console-tools package, which can be found
at http://lct.sourceforge.net/
$ loadkeys --version
loadkeys: (console-tools) 0.2.3
--
`O O' | [EMAIL PROTECTED]
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
From: Riley Williams <[EMAIL PROTECTED]>
Neither am I - but, according to comments from RedHat a while back,
they repackage mount separately because they provide a NEWER version
of mount than is in the util-linux package. This will ALSO result in
`mount --version` giving the wrong answer...
There is no newer version.
In ancient times I came with frequent releases of mount, at a time
when util-linux was released very infrequently. These years mount
is part of util-linux, and util-linux is released frequently.
Unless one can guarantee that the util-linux and mount packages are
the SAME version, mount can't be guaranteed to report the version of
the util-linux package installed. RedHat provide a NEWER version of
mount to util-linux so that guarantee doesnae exist.
I do not think they do.
> You are mistaken, as is proved by the reports that contain a kbd
> line: a grep on linux-kernel for this Februari shows people with
> Kbd 0.96, 0.99 and 1.02.
{Shrug} Please explain why I was unable to get ver_linux to report a
When other people can and you cannot, why should I explain your failure?
Let me just check. A version from 1993:
% ./loadkeys -h 2>&1 | head -1
loadkeys version 0.81
A version from 2001:
% ./loadkeys -h 2>&1 | head -1
loadkeys version 1.06
Maybe nothing has changed here the past eight years. It just works.
Perhaps you tried some modified version.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
> [Yes, I wrote, replying to your mail, just because I happened to
> notice the incorrect or debatable lines in your patch. Let me cc
> the Changes maintainer - maybe Chris Ricker.]
-o util-linux 2.10o # fdformat --version
+o util-linux # 2.10o# fdformat --version
>>> Looking at fdformat to get the util-linux version is perhaps not
>>> the most reliable way - some people have fdformat from elsewhere.
>>> Using mount --version would be better - I am not aware of any
>>> other mount distribution.
>> RedHat distribute mount separately from util-linux and I
>> wouldnae be surprised if others do the same...
> I am not aware of any distribution that ships some version of
> util-linux, but replaces its mount part by an older version. I
> think that even in cases where, because of historical reasons,
> util-linux is repackaged in several parts, mount --version gives
> the right answer.
Neither am I - but, according to comments from RedHat a while back,
they repackage mount separately because they provide a NEWER version
of mount than is in the util-linux package. This will ALSO result in
`mount --version` giving the wrong answer...
+In addition, it is wise to ensure that the following packages are
+at least at the versions suggested below, although these may not
+be required, depending on the exact configuration of your system:
+
+o Console Tools # 0.3.3# loadkeys -V
+o Mount # 2.10e# mount --version
>>> Concerning mount:
>>>
>>> (i) the version mentioned is too old,
>> As stated in my original post, I've no idea what the correct
>> version should be as it's not documented anywhere I can find.
>>> (ii) mount is in util-linux.
>> Not on RedHat systems.
> There is no other source. Some people like to repack but that
> has no influence on versions.
Unless one can guarantee that the util-linux and mount packages are
the SAME version, mount can't be guaranteed to report the version of
the util-linux package installed. RedHat provide a NEWER version of
mount to util-linux so that guarantee doesnae exist.
>>> Conclusion: the mount line should be deleted entirely.
Conclusion: Both the mount and util-linux lines are REQUIRED.
>>> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
>>> I am not aware of any reason to recommend the use of
>>> console-tools.
>> Neither am I. The ver_linux script has lines for determining the
>> versions for both Console Tools and Kbd but on EVERY system I've
>> tried, including Slackware, RedHat, Debian, Caldera, and SuSE
>> based ones, the line for determining Kbd versiondoesnae work.
>> I've just included the line that worked, and ignored the Kbd one
>> as I can see no point including something that doesnae work.
> You are mistaken, as is proved by the reports that contain a kbd
> line: a grep on linux-kernel for this Februari shows people with
> Kbd 0.96, 0.99 and 1.02.
{Shrug} Please explain why I was unable to get ver_linux to report a
kbd line on ANY of the systems I tried, including systems with it
definately installed. I tried it out manually on several such systems,
and ALL reported the SAME error message to the `loadkeys -h` command
used in scripts/ver_linux which is:
Q> $ loadkeys -h 2>&1 > x
Q> Usage: loadkeys [option...] [mapfile...]
Q> valid options are:
Q> -c --clearcompose clear kernel compose table
Q> -d --default load default keymap file
Q> -m --mktable output a "defkeymap.c" to stdout
Q> -s --clearstrings clear kernel string table
Q> -q --quietbe silent
Q> -v --verbose report the changes
Q> -v --verbose report more changes
Q> -h --help display this help text and exit
Q> -V --version display version information and exit
Q> $
Also, please advise where the version number is in that text...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
[EMAIL PROTECTED] wrote: > > On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: > > >>> +o Console Tools # 0.3.3# loadkeys -V > >>> +o Mount # 2.10e# mount --version > >> > >> Concerning mount: (i) the version mentioned is too old, > On the other hand, there are no important changes between > mount-2.10d and 2.10e, so I see no justification for writing 2.10e. > It is difficult to say what the "right" version is. There is a > long series of minor improvements. Probably I would write 2.10r. Guys, How about making a column that says: "recommended". So in this case we'd see 2.10r as recommended, but 2.10e as required. An explanation could state that: if you happen to have the version under "required", but a higher version is listed under "recommended", then that newer version is available, and but it is likely that one you have will work for you. There is no urgent reason to upgrade. But if you happen to be upgrading, you are advised upgrade to at least the version in the "recommended" column, as that has fixes over the one mentioned in the "required" column. Best regards, Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
From: "Albert D. Cahalan" <[EMAIL PROTECTED]> > On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: >>> +o Console Tools # 0.3.3# loadkeys -V >>> +o Mount # 2.10e# mount --version >> >> Concerning mount: (i) the version mentioned is too old, Exactly why? Mere missing features don't make for a required upgrade. Version number inflation should be resisted. These days you can mount filesystems several places. That means that the choice one used to have -- after # mount dev dir both # umount dev and # umount dir would unmount -- has disappeared, and only # umount dir is (guaranteed to be) right today. These days you can mount several filesystems at the same mount point. The old mount does not understand this at all. Recent versions of mount act better in this respect, even though it is still easy to confuse them. Such things mean that it is best to have a really recent mount (although, of course, if you only want the mount(2) system call executed some five year old version will also do that for you). On the other hand, there are no important changes between mount-2.10d and 2.10e, so I see no justification for writing 2.10e. It is difficult to say what the "right" version is. There is a long series of minor improvements. Probably I would write 2.10r. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Alexander Viro writes: > On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: >>> +o Console Tools # 0.3.3# loadkeys -V >>> +o Mount # 2.10e# mount --version >> >> Concerning mount: (i) the version mentioned is too old, Exactly why? Mere missing features don't make for a required upgrade. Version number inflation should be resisted. >> Concerning Console Tools: maybe kbd-1.05 is uniformly better. >> I am not aware of any reason to recommend the use of console-tools. > > Debian has console-tools with priority:required and kbd > with priority:extra. Take it with Yann Dirson... Both should be "extra". They can be removed from the version script. I'm even one of the few remaining console users. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
On Wed, Mar 14, 2001 at 08:29:53PM +0100, [EMAIL PROTECTED] wrote: > There is no other source. Some people like to repack but that > has no influence on versions. I believe that RedHat don't build mount and util-linux from the same tree. Maybe they do internally, but when you look at the RPMs, they appear separate: Name: mount Source RPM: mount-2.10m-6.src.rpm Name: util-linux Source RPM: util-linux-2.10m-12.src.rpm There don't appear to be any explicit dependencies between these two packages either, but they do just happen to have the same version. (I'm looking at the RH7.0 RPMs here). This of course means that the version of mount may not match the version of util-linux installed on the system. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
From: Riley Williams <[EMAIL PROTECTED]> [Yes, I wrote, replying to your mail, just because I happened to notice the incorrect or debatable lines in your patch. Let me cc the Changes maintainer - maybe Chris Ricker.] >> -o util-linux 2.10o # fdformat --version >> +o util-linux # 2.10o# fdformat --version > Looking at fdformat to get the util-linux version is perhaps not > the most reliable way - some people have fdformat from elsewhere. > Using mount --version would be better - I am not aware of any > other mount distribution. RedHat distribute mount separately from util-linux and I wouldnae be surprised if others do the same... I am not aware of any distribution that ships some version of util-linux, but replaces its mount part by an older version. I think that even in cases where, because of historical reasons, util-linux is repackaged in several parts, mount --version gives the right answer. >> +In addition, it is wise to ensure that the following packages are >> +at least at the versions suggested below, although these may not >> +be required, depending on the exact configuration of your system: >> + >> +o Console Tools # 0.3.3# loadkeys -V >> +o Mount # 2.10e# mount --version > Concerning mount: > > (i) the version mentioned is too old, > (ii) mount is in util-linux. Not on RedHat systems. There is no other source. Some people like to repack but that has no influence on versions. > Conclusion: the mount line should be deleted entirely. > Concerning Console Tools: maybe kbd-1.05 is uniformly better. > I am not aware of any reason to recommend the use of console-tools. Neither am I. The ver_linux script has lines for determining the versions for both Console Tools and Kbd but on EVERY system I've tried, including Slackware, RedHat, Debian, Caldera, and SuSE based ones, the line for determining Kbd versiondoesnae work. I've just included the line that worked, and ignored the Kbd one as I can see no point including something that doesnae work. You are mistaken, as is proved by the reports that contain a kbd line: a grep on linux-kernel for this Februari shows people with Kbd 0.96, 0.99 and 1.02. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
>> -o util-linux 2.10o # fdformat --version
>> +o util-linux # 2.10o# fdformat --version
> Looking at fdformat to get the util-linux version is perhaps not
> the most reliable way - some people have fdformat from fd-utils
> or so.
{Shrug} That's the command that was in both Documentation/Changes and
in scripts/ver_linux and I just left what was already there, as shown
by your quote. Somebody MUCH more knowledgable than me regarding
kernel requirements can sort that out.
> Using mount --version would be better - I am not aware of any
> other mount distribution.
RedHat distribute mount separately from util-linux and I wouldnae be
surprised if others do the same...
>> +In addition, it is wise to ensure that the following packages are at least
>> +at the versions suggested below, although these may not be required,
>> +depending on the exact configuration of your system:
>> +
>> +o Console Tools # 0.3.3# loadkeys -V
>> +o Mount # 2.10e# mount --version
> Concerning mount:
>
> (i) the version mentioned is too old,
Probably. As stated, that's what's currently installed here, and I
havenae the foggiest whether any of them need upgrading as there's
nothing I've been able to find to say what the minimum version is.
> (ii) mount is in util-linux.
Not on RedHat systems.
> Conclusion: the mount line should be deleted entirely.
Maybe, but that's not for me to decide. Whoever wrote ver_linux
obviously thought it important.
> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
> I am not aware of any reason to recommend the use of console-tools.
Neither am I. The ver_linux script has lines for determining the
versions for both Console Tools and Kbd but on EVERY system I've
tried, including Slackware, RedHat, Debian, Caldera, and SuSE based
ones, the line for determining Kbd versiondoesnae work. I've just
included the line that worked, and ignored the Kbd one as I can see no
point including something that doesnae work.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
[EMAIL PROTECTED] writes: >Looking at fdformat to get the util-linux version is perhaps >not the most reliable way - some people have fdformat from fd-utils or so. >Using mount --version would be better - I am not aware of any >other mount distribution. Bad idea. RedHat has mount and util-linux in different RPMs (at least 6.x). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
> Many systems have mount (and bsdutils) separated from util-linux > as a binary package. Built from the same source, indeed, but... I hope that this habit is dying. Long ago that was reasonable, but these days (years) it only causes extra work. >> Concerning Console Tools: maybe kbd-1.05 is uniformly better. >> I am not aware of any reason to recommend the use of console-tools. > Debian has console-tools with priority:required and kbd with priority:extra. > Take it with Yann Dirson... I am not aware of any reason to recommend the use of console-tools. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: > > +o Console Tools # 0.3.3# loadkeys -V > > +o Mount # 2.10e# mount --version > > Concerning mount: (i) the version mentioned is too old, > (ii) mount is in util-linux. Conclusion: the mount line > should be deleted entirely. Many systems have mount (and bsdutils) separated from util-linux as a binary package. Built from the same source, indeed, but... > Concerning Console Tools: maybe kbd-1.05 is uniformly better. > I am not aware of any reason to recommend the use of console-tools. Debian has console-tools with priority:required and kbd with priority:extra. Take it with Yann Dirson... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
On Wed, Mar 14, 2001 at 10:39:53AM +, Riley Williams wrote: > -o util-linux 2.10o # fdformat --version > +o util-linux # 2.10o# fdformat --version Looking at fdformat to get the util-linux version is perhaps not the most reliable way - some people have fdformat from fd-utils or so. Using mount --version would be better - I am not aware of any other mount distribution. > +In addition, it is wise to ensure that the following packages are at least > +at the versions suggested below, although these may not be required, > +depending on the exact configuration of your system: > + > +o Console Tools # 0.3.3# loadkeys -V > +o Mount # 2.10e# mount --version Concerning mount: (i) the version mentioned is too old, (ii) mount is in util-linux. Conclusion: the mount line should be deleted entirely. Concerning Console Tools: maybe kbd-1.05 is uniformly better. I am not aware of any reason to recommend the use of console-tools. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Improved version reporting
Hi all. As a result of private email correspondance I have recently received, I became aware that the current system of identifying the versions of the various subsystems required to support any particular kernel version is inadequate, and decided to do something about it. The enclosed patch is my offering to rectify this. The problems identified are: 1. Different subsystems are identified in Documentation/Changes and in scripts/ver_linux, probably due to the difficulty of maintaining two files in sync with each other. As a result, it is not clear what the required versions of some subsystems are. 2. The existing script does not make it clear which subsystems need to be updated. The user is expected to decide by cross-referencing the details it provides with those provided elsewhere. 3. The command to perform this analysis is not immediately obvious. My offering (developed against the 2.4.2 kernel source tree) does away with all three of these problems by: A. Making Documentation/Changes the sole source of information on the subsystems required. The script I have developed then reads the table in this file, and uses commands listed therein to determine the installed versions of the relevant subsystems. The format of this table had to be changed slightly to accommodate the script, but this was done without impairing the readability thereof. B. Adding lines to Documentation/Changes to document those subsystems listed by scripts/ver_linux that were not already in the table in Documentation/Changes so that all relevant subsystems are considered. This was done by adding a separate table formatted identically to the existing one, but indicating that the subsystems therein may not be required. Note that the "required versions" listed in this new table are those installed on my system, with the exception of the Linux C++ library which is apparently not installed here. These versions need to be tweaked to reflect the actual requirements for that kernel. C. Comparing the installed and required versions of each subsystem, and indicating the results of that comparison in the displayed results by colouring the name of the subsystem. A facility to disable this is also included, and is activated by providing a parameter to the script. Any parameter will serve this function. D. Inserting lines in the primary Makefile to allow `make vsn` to run the relevant command to generate the results with colouring, and `make vsnbw` to do so without colours. Both change the permissions of the script to make it an executable. There is ONE problem with this method, which I have not been able to solve. This is that the command used by scripts/ver_linux to determine the installed version of the Gnu C Library can't be replicated using the method this script is based on, and I have had to replace it with a simpler script which may produce different results in some cases. If this is a problem, it is open to others to solve as I have licensed this under version 2 (only) of the Gnu General Public Licence. Best wishes from Riley. --- linux/Documentation/Changes~Fri Feb 16 23:53:08 2001 +++ linux/Documentation/Changes Tue Mar 13 23:38:46 2001 @@ -48,16 +48,31 @@ Card) hardware, for example, you probably needn't concern yourself with pcmcia-cs. -o Gnu C 2.91.66 # gcc --version +o Gnu C # 2.91.66 # gcc --version -o Gnu make 3.77# make --version +o Gnu make # 3.77 # make --version -o binutils 2.9.1.0.25 # ld -v +o binutils # 2.9.1.0.25 # ld -v -o util-linux 2.10o # fdformat --version +o util-linux # 2.10o# fdformat --version -o modutils 2.4.2 # insmod -V +o modutils # 2.4.2# insmod -V -o e2fsprogs 1.19# tune2fs +o e2fsprogs # 1.19 # tune2fs -o reiserfsprogs 3.x.0b # reiserfsck 2>&1|grep reiserfsprogs +o reiserfsprogs # 3.x.0b # reiserfsck 2>&1|grep reiserfsprogs -o pcmcia-cs 3.1.21 # cardmgr -V +o pcmcia-cs # 3.1.21 # cardmgr -V -o PPP2.4.0 # pppd --version +o PPP# 2.4.0# pppd --version /dev/tty -o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version +o isdn4k-utils # 3.1pre1 # isdnctrl 2>&1|grep version + +In addition, it is wise to ensure that the following packages are at least +at the versions suggested below, although these may not be required, depending +on the exact configuration of your system: + +o Console Tools # 0.3.3# loadkeys -V +o Current Kernel #
