[lsb-discuss] Re: New uname option to query exact OS distribution
Tobias Burnus
burnus at net-b.de
Wed Aug 25 09:55:52 PDT 2004
Hello,
Wichmann, Mats D wrote:
>>I for one don't see any reason to add a 'uname -d' if lsb-release is
>>already specified. I imagine that it's easier for utilities to
>>check for the existence of the lsb-release executable than it is to
>>check for uname's support of a -d flag.
>>
>>
>The only concern is that most systems don't have it installed;
>it takes either a conscious request by the sysadmin or installation
>of a package that has a dependency on it, making it a far less
>general solution than convincing uname to return more info.
>
>
I think that uname does a good job for things that it is thought for
(machine [i686,alpha], system [Linux,OSF1], etc.). Granted that the
release number is not always useful (Tru64's "V5.1" is nicer than
'2.6.5-7.104-default' or '2.4.26-nfsacl-modlibata-drbd-acpi-smp-1'), but
even knowing which distribution one uses doesn't help much since there
can be several manually installed packages.
But if one sticks to LSB features, one can simply require "lsb" and has
thus lsb_release (and no need for lsb_release -i).
If one wants to do distribution specific things, one needs - anyway - an
in-depth understanding of the distribution and can thus directly use
/etc/{debian_version, SuSE-release,RedHat-release} etc.
I don't see any action required/useful regarding 'uname', neither from
the LSB nor (and especially not) from the Austin Group.
>Which I'm not sure I advocate - do we really want to encourage
>more ways in which software can be "distro specific"?
>
>
I think lsb_release (with underscore) is enough. The problem that
lsb_release is not installed by default has do to with two things.
First, there are not that many applications which depend on the "lsb"
package. Secondly, for a fully complient LSB system, tons of other
packages have to installed.
On a SUSE Linux 9.1 system, lsb.rpm contains /dev/MAKEDEV,
/etc/init.d/lsb (for ngroups_max), /etc/lsb-release, /lib/ld-lsb.so.1
(symlink), /usr/bin/lsb_release and
/usr/share/man/man1/lsb_release.1.gz; i.e. lsb.rpm uses almost no space.
But of one looks at the package requirements, a long list with packages
such as pax, XFree86-libs, glibc-i18ndata and rsync is shown. At least
some of them are rather bulky (glibc-i18ndata ~10MB, X11 libs) or hardly
ever needed (pax). Some dependency origines also in scripts like
install_initd (such as Python for Debian's).
The merit of changing uname is that it is always(?) installed and that
the distributions won't create two version of uname, a 'normal' one and
a LSB conform. Other than that I don't see any compelling reason for
changing uname.
There are two ways out: more LSB applications and modulizing of the LSB
to reduce the number of the minimal set of extra packages. The first
thing seems to be slowly happen (currently, the LSB seems to be more a
guideline on features common to all Linuxes rather than a strict
implementation policy), while LSB 2.0 is the right step with regard to
the latter. (One has only to make sure that LSB-core gets installed by
default while the rest is provided by other lsb-* packages.)
Regards,
Tobias
More information about the lsb-discuss
mailing list