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

Dr. Giovanni A. Orlando gorlando at futuretg.com
Thu Aug 26 10:28:27 PDT 2004

Tobias Burnus wrote:


    Will someone implement this feature ?

    Today, I start to implement, and see that on rpm-based distro, 
likes: RedHat, Yellowdog, FTOSX, etc
    haves the file, "/etc/'distro-name'-release that may be got from rpm 

    I also note that generally, all these distro haves no differents at 
all between company name and distro name:

    * Company name: YellowDog,
    * Distro name = "Company-Name" Linux

    We instead adopt vendor: "ftosx", more similar to other 
rpm-implementations, and use Vendor: Future Technologies Inc
    inside the of "futuretg".
    Mandrake adopt a similar approach, because the name of the OS is 
different that the name of company, MandrakeSoft.

    So, a first step is to use rpm commands to get additional info. 
Debian, and UNIX is another matter.

    Therefore, I am looking to implement: '-d' for the distro name, as 
well, 'w' for the vendor website. Add anoter flag
    may be used to describe the vendor.

    If we need to feedback ... please update.


> 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



Check FT Websites ... 
http://www.futuretg.com  - ftp://ftp.futuretg.com


More information about the lsb-discuss mailing list