What is more detailled than $^O ?

[Yohan N Leder]

I've read the thread; and I didn't see you had solved a Perl problem
anywhere in the thread.

It's your right to have an opinion

 

[Yohan N Leder]

so I'll switch to "End of Thread" mode here.

Good decision, I agree with you for my own case too

 

[Ted Zlatanov]

You surely know the sentence : "Tell me what you need and I'll tell you
how to do without"... Really and independently to the kindly of your
post, I'll don't debate about the pertinence or not of the choice, but
how to achieve this precise choice : I'm not alone here, but just the
one who has to achieve this specific choice these days... So, I'll do it
whatever be the way to succeed...

That's great. Just remember, the right solution is not always the one
that works immediately, or the easiest one. Sometimes, in Perl as in
life in general, you have to see past the immediate problem and
anticipate the problems you'll have later because of a fast/easy
solution now.

Just because your team thinks fast/easy is right doesn't make it the
right choice, either. Sometimes you have to stop the team if they are
walking off a cliff blindfolded ("but it's downhill!").

Ted

 

[Peter J. Holzer]

If one is writing an installer, it might be useful to know if one is
to use yum, apt-get, or yast to install any dependencies,

So test for the availability of these tools. A stock redhat system
hasn't any of these tools, but the sysadmin might have installed yum or
apt (most of my redhat systems have apt). it might even be possible to
deinstall yast on a suse system.

or which package to prompt the user to install.

Yes, but it generally needs quite special knowledge which changes
frequently. A feature provided by package X in version n might be
provided by package Y in version n+1. So as a hint for the user that's
helpful ("I can't find libfoo, since you are on a Redhat system, it is
probably included in the foo2-devel package", or something like that),
but the same information could just be contained in the README without
any real loss of functionality.

If one is writing a test harness, it's often useful to be able to
report to the person reading the test results what distro was
installed on the system under test.

Right. The distribution (among other details about the environment) is
something you frequently want to include in reports of some kind: Bug
reports (to make it easier to reproduce the problem), configuration
reports (How many servers running desupported OS versions are we still
running?), etc.


To adapt the behaviour of the program to its environment, there are
usually more direct and reliable indicators than the distribution.

hp

 

[Eric Schwartz]

So test for the availability of these tools.

This doesn't necessarily give you what you need. For instance, RHEL3
may need packages a-1.3.rpm, b-2.4.rpm, and so on, but RHEL4 might
need a-1.9.rpm, and b-3.7.rpm. Also, I frequently have Debian systems
with rpm installed, and as you point out, below, many RPM-based
distros have apt tools available. So knowing the tools available
doesn't tell you anything about which set of dependent packages to
install, which is usually the hard problem.

A stock redhat system hasn't any of these tools, but the sysadmin
might have installed yum or apt (most of my redhat systems have
apt). it might even be possible to deinstall yast on a suse system.

Right-- which means that testing for the tools may not tell you want
you want to know, because, depending on the ordering of the check, you
may end up deciding you're on the wrong sort of system.

Yes, but it generally needs quite special knowledge which changes
frequently.

"Frequently", in the context I'm thinking of, is "every two years or
so", which is fairly manageable.

A feature provided by package X in version n might be provided by
package Y in version n+1.

This is trivially handle-able. Which is why it's useful to know these
things.

So as a hint for the user that's helpful ("I can't find libfoo,
since you are on a Redhat system, it is probably included in the
foo2-devel package", or something like that), but the same
information could just be contained in the README without any real
loss of functionality.

I disagree; being forced to handle something manually which could be
handled automatically counts as a real loss of functionality in my
book. That's not to say it's either a) fun or b) a good idea in all
cases, but there are times it's good to know these things, and to be
able to handle them without resorting to making an end-user work
around it for you.

A suggestion such as you make is nice if you're trying to make your
installer forward-compatible with distros you don't know about when
the installer is written, but if you can know the answer, why not use
that information?

To adapt the behaviour of the program to its environment, there are
usually more direct and reliable indicators than the distribution.

Usually-- but not always, which was more or less my point.

-=Eric

 

[Peter J. Holzer]

This doesn't necessarily give you what you need. For instance, RHEL3
may need packages a-1.3.rpm, b-2.4.rpm, and so on, but RHEL4 might
need a-1.9.rpm, and b-3.7.rpm.

First you ware talking about packaging tools, now you are talking about
specific packages. This is exactly the confusion I want to avoid.

If you want to know which tools to use, check for the tools. If you want
to know about the packages, check the packages.

Right-- which means that testing for the tools may not tell you want
you want to know, because, depending on the ordering of the check, you
may end up deciding you're on the wrong sort of system.

That's what I'm talking about: CHECK WHAT YOU NEED TO KNOW. Don't check
something else and then draw conclusions.

I remember very well the #ifdef jungles of C programs in the
1990's: They started simple: Often there was a BSD and SysV-way to do
something, so programmers started with

#ifdef bsd
do_it_the_bsd_way()
#else
do_it_the_sysv_way()
#endif

But of course many Unixes were a mixture, so that quickly became

#ifdef bsd
#ifdef foonix
do_it_the_sysv_way();
#else
do_it_the_bsd_way();
#endif
#else
#ifdef barnix
do_it_the_bsd_way();
#elsif gazonkux
do_it_the_sysv_way_except_with_a_workaround_for_a_bug();
#else
do_it_the_sysv_way()
#endif
#endif

and then barnix switched to sysvish behaviour in version 5, so this
became

#ifdef bsd
#ifdef foonix
do_it_the_sysv_way();
#else
do_it_the_bsd_way();
#endif
#else
#ifdef barnix
#if barnix > 1000
do_it_the_sysv_way();
#else
do_it_the_bsd_way();
#endif
#elsif gazonkux
do_it_the_sysv_way_except_with_a_workaround_for_a_bug();
#else
do_it_the_sysv_way()
#endif
#endif

and so on: For a dozen Unix variants with lots of versions, and usually
not in a clean tree like I've shown above, but with lots of && and ||
and sections which applied to several variants, etc. An absolutely
unmaintainable mess.

Later people started to test for specific features, like

#include "config.h"
#if HAVE_SYSVISH_GADGET
do_it_with_sysvish_gadget();
#elsif HAVE_BSDISH_GADGET
do_it_with_bsdish_gadget();
#else
#error
#end

and either let the sysadmin edit the config.h or use a script to create
it automatically, by actually testing whether
do_it_with_sysvish_gadget() and do_it_with_bsdish_gadget() are working.

I disagree; being forced to handle something manually which could be
handled automatically counts as a real loss of functionality in my
book.

I would strongly object to a package which installs other packages
during the build process (actually, it can't do that since I don't
normally build stuff as root). Automatic resolving of dependencies
belongs into the packaging system.

A suggestion such as you make is nice if you're trying to make your
installer forward-compatible with distros you don't know about when
the installer is written, but if you can know the answer, why not use
that information?

Writing an installer for linux is an error. I curse every vendor who
provides their own installer instead of using the package management
system of the distribution.

hp

 

[Dave Weaver]

I would like to distinguish the accurate linux distribution when $^O is
'linux'. How to do ? Do I have to figure-out searching for trace of
distribution name in some environment variables like SERVER_SOFTWARE or
SERVER_SIGNATURE which may contains a reference to the operating system
under which the web server has been built for ? Something better in mind
?

Others have already pointed out the issues with what you want to
do.

However some distributions (and I've no idea how common this is, it
may only be the 2 distributions I have handy, so beware) contain a
file /etc/XXXXX-release which contains distribution version info.

For example on the system I'm writing this post on, there is a
/etc/gentoo-release with the content: "Gentoo Base System version 1.6.14"

On another machine of mine there is a /etc/redhat-release with the
content: "Red Hat Enterprise Linux WS release 3 (Taroon Update 4)"

Perhaps that is the sort of thing you're looking for. But this isn't
really a Perl question, it's a Linux question, and you should be
asking elsewhere, probably in some linux group.