|
From: | Tobias Burnus |
Subject: | Re: [lsb-discuss] Re: New uname option to query exact OS distribution |
Date: | Wed, 25 Aug 2004 18:55:52 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 |
Hello, Wichmann, Mats D wrote:
I for one don't see any reason to add a 'uname -d' if lsb-release isalready specified. I imagine that it's easier for utilities to check for the existence of the lsb-release executable than it is tocheck 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.
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.Which I'm not sure I advocate - do we really want to encourage more ways in which software can be "distro specific"?
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
[Prev in Thread] | Current Thread | [Next in Thread] |