canonical way to detect platform/distribution

[Brian Reichert]

I'm trying to design a spec file that does different things depending
on the distribution. But, I can't see a canonical way of doing it.

My current development platform is CentOS 5.1.

On this list, and on the net, I've seen this construct

%if 0%{?fedora} > 4 || 0%{?rhel} > 4
# do stuff
%endif

or this:

%if 0%{rhel_version}%{centos_version} == 0
# do stuff
%endif

but none of these sorts of macros seem to be defined by the rpmbuild
universe.

'rpm --showrc' doesn't seem to provide any clues about distribution or
platform.

Any advice out there? Pointers welcome...

[Jeff Johnson]

Post by Brian Reichert
I'm trying to design a spec file that does different things depending
on the distribution. But, I can't see a canonical way of doing it.
My current development platform is CentOS 5.1.
On this list, and on the net, I've seen this construct
%if 0%{?fedora} > 4 || 0%{?rhel} > 4
# do stuff
%endif
%if 0%{rhel_version}%{centos_version} == 0
# do stuff
%endif
but none of these sorts of macros seem to be defined by the rpmbuild
universe.
'rpm --showrc' doesn't seem to provide any clues about distribution or
platform.
Any advice out there? Pointers welcome...

You likely need to install the redhat-rpm-config package, that's usually
where
vendor peculier macros are supplied by RHEL.

73 de Jeff

[Brian Reichert]

Post by Jeff Johnson
You likely need to install the redhat-rpm-config package, that's usually
where
vendor peculier macros are supplied by RHEL.

Thanks; I'll give that a try!

Post by Jeff Johnson
73 de Jeff

[devzero2000]

IMHO, the general problem of vendor rpm fragmentation isn't likely to be
resolved
with rpm macros. But for a single distro (rhel vs suse vs mandriva vs ...)
and different release of this, it is a possibility: not good in general but
it's life...............

Macros if abused are for itself a source of incompatibility: use it
carefully. I know it is not so simple but a little discipline and more QA in
rpm packaging it is often necessary
if not desiderable always, AFAICT.

Regards

Post by Jeff Johnson

Post by Brian Reichert
I'm trying to design a spec file that does different things depending
on the distribution. But, I can't see a canonical way of doing it.
My current development platform is CentOS 5.1.
On this list, and on the net, I've seen this construct
%if 0%{?fedora} > 4 || 0%{?rhel} > 4
# do stuff
%endif
%if 0%{rhel_version}%{centos_version} == 0
# do stuff
%endif
but none of these sorts of macros seem to be defined by the rpmbuild
universe.
'rpm --showrc' doesn't seem to provide any clues about distribution or
platform.
Any advice out there? Pointers welcome...

You likely need to install the redhat-rpm-config package, that's usually
where
vendor peculier macros are supplied by RHEL.
73 de Jeff
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[Michael Jennings]

On Saturday, 19 April 2008, at 22:17:53 (+0200),

Post by devzero2000
IMHO, the general problem of vendor rpm fragmentation isn't likely
to be resolved with rpm macros. But for a single distro (rhel vs
suse vs mandriva vs ...) and different release of this, it is a
possibility: not good in general but it's life...............

Using standard macros is a great way to improve portability. For
example, using "%{__mkdir_p}" instead of "mkdir -p" helps packages
port to platforms that do not have GNU mkdir (since %{__mkdir_p} could
easily be defined to "mkdirhier" or some flavor of "mkinstalldirs"
instead of the GNU-specific "mkdir -p") and allows vendors like IBM or
Sun to repoint various commands independent of the value of $PATH
(e.g., %{__install} could use /usr/ucb/install instead of
/usr/bin/install).

The problems arise when packagers use non-portable macros that are
specific to their proprietary little sandboxes (e.g., %{make} on
Mandr[ai][kv][ea], %{__id_u} on Fedora, etc.). Too many vendors
couldn't care less about whether or not their packages build on other
distros, completely ignoring the plight of independent packagers and
ISVs.

Michael