Re: [lsb-discuss] Re: New uname option to query exact OS distribution

[Tobias Burnus]

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