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

[Dr. Giovanni A. Orlando]

Tobias Burnus wrote:

Hi,

   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 
commands.

   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.

Thanks,
Giovanni

> 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
http://www.FTLinuxCourse.com
        http://www.FTLinuxCourse.com/Certification
http://www.rpmparadaise.org
http://GNULinuxUtilities.com
http://www.YourPersonalOperatingSystem.com

--