Building optimized and non-optimized versions of the same rpm

[Carter Sanders]

Hi -

My company has a need to build both optimized and non-optimized
flavors of the same RPM. The issue is not about the debug symbols table,
but rather that various C++ optimizations make it difficult to debug the
executables, even if you don't strip the symbols.

Consequently, we want to build and manage both flavors. Is there a
recommended procedure for distinguishing two rpms that have identical
source but have been compiled with different flags? I was considering
altering the "Release:" field to have a suffix "_optimized" or
"_unoptimized". I also could actually change the name of the rpm to
reflect the flavor, but I'm concerned that will introduce dependency
problems.

I could set up separate yum servers for each flavor, but I'm
concerned about users being unable to easily tell which flavor an rpm is
once it's installed.

Has anybody out there got a good approach for handling this? Thanks
in advance.

-Carter

[devzero2000]

An idea could be the following.

Let me call the package as <PKGNAME> for this example. I also suppose that
exists only, in a certain time, a single version of the package: the
"optimized" or the "notoptimized" installed and that i want the packages
distinguished not only for name but for some metadata informations. In
particular in rpm this metadata information is in the optflags tag.

So:

First Package SPEC snip (e.g without optimization) (named as
PACKAGENAME-without-opt.spec)
--------------------------------------------------------------------------
%define optflags <what do you thinks are the flags without opt >
############################################
# for one example if one want the default without -g this is :
# %{expand:%%define optflags %( echo %optflags | sed 's/-g//g') }
#############################################
Name: <PACKAGENAME>-opt
Version : 1.0
Release: 1
Provides: <PACKAGENAME> = %{version}-%{release}
Obsoletes: <PACKAGENAME> <= %{version}
.
.
.
%build
###################
# use %configure or
# something like this
#
# CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ;
# CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ;
# FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ;
# ./configure ......





Second Package SPEC snip (e.g with optimization) (named
PACKAGENAME-opt.spec)
--------------------------------------------------------------------------
%define optflags <what do you thinks must go for opt flags >
############################################
# for example the default with -g always appended as this
# %{expand:%%define optflags %( echo "%optflags -g") }
#############################################
Name: <PACKAGENAME>-without-opt
Version : 1.0
Release: 1
Provides: <PACKAGENAME> = %{version}-%{release}
Obsoletes: <PACKAGENAME> <= %{version}

%build
# as before in the first package



Now you have

1- only a package installable : <PACKAGENAME>-opt or
<PACKAGENAME>-without-opt
2 - if you have <PACKANAME>-opt installed and you do : rpm -Uvh
<PACKAGENAME>-without-opt-1.0-1.<arch>.rpm
you have <PACKAGENAME>-without-opt installed and <PACKANAME>-opt
disinstalled : it is also true the reverse.
3 - The package dependency from <PACKAGENAME>, if exists, are preserved
4- And, for control, you can do an rpm query thereafter on optflags. For
example
rpm -q --qf '%{optflags}' <PACKAGENAME>-opt and see if the optflags are
correct

hth

Hi -
My company has a need to build both optimized and non-optimized flavors
of the same RPM. The issue is not about the debug symbols table, but rather
that various C++ optimizations make it difficult to debug the executables,
even if you don't strip the symbols.
Consequently, we want to build and manage both flavors. Is there a
recommended procedure for distinguishing two rpms that have identical source
but have been compiled with different flags? I was considering altering the
"Release:" field to have a suffix "_optimized" or "_unoptimized". I also
could actually change the name of the rpm to reflect the flavor, but I'm
concerned that will introduce dependency problems.
I could set up separate yum servers for each flavor, but I'm concerned
about users being unable to easily tell which flavor an rpm is once it's
installed.
Has anybody out there got a good approach for handling this? Thanks in
advance.
-Carter
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[Carter Sanders]

Thanks, but I don't think that will work for me, because I will have
have packages that require <PACKAGENAME>, and if I add -opt to the end
of it, I won't be able to swap out the unoptimized for the optimized
without ingoredeps, which I sometime do for debugging.

I noticed the optflags field, but I'm concerned it won't be readily
apparent to the support engineers the way a change in the build number
would be (they may not know about "rpm -q --qf "). So I think I'll stick
with my idea of appending the _opt or _unopt to the end of "Release". It
will have some funny effects on update logic, but I can handle it.

Post by devzero2000
An idea could be the following.
Let me call the package as <PKGNAME> for this example. I also suppose
the "optimized" or the "notoptimized" installed and that i want the
packages distinguished not only for name but for some metadata
informations. In particular in rpm this metadata information is in
the optflags tag.
First Package SPEC snip (e.g without optimization) (named as
PACKAGENAME-without-opt.spec)
--------------------------------------------------------------------------
%define optflags <what do you thinks are the flags without opt >
############################################
# %{expand:%%define optflags %( echo %optflags | sed 's/-g//g') }
#############################################
Name: <PACKAGENAME>-opt
Version : 1.0
Release: 1
Provides: <PACKAGENAME> = %{version}-%{release}
Obsoletes: <PACKAGENAME> <= %{version}
.
.
.
%build
###################
# use %configure or
# something like this
#
# CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ;
# CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ;
# FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ;
# ./configure ......
Second Package SPEC snip (e.g with optimization) (named
PACKAGENAME-opt.spec)
--------------------------------------------------------------------------
%define optflags <what do you thinks must go for opt flags >
############################################
# for example the default with -g always appended as this
# %{expand:%%define optflags %( echo "%optflags -g") }
#############################################
Name: <PACKAGENAME>-without-opt
Version : 1.0
Release: 1
Provides: <PACKAGENAME> = %{version}-%{release}
Obsoletes: <PACKAGENAME> <= %{version}
%build
# as before in the first package
Now you have
1- only a package installable : <PACKAGENAME>-opt or
<PACKAGENAME>-without-opt
2 - if you have <PACKANAME>-opt installed and you do : rpm -Uvh
<PACKAGENAME>-without-opt-1.0-1.<arch>.rpm
you have <PACKAGENAME>-without-opt installed and <PACKANAME>-opt
disinstalled : it is also true the reverse.
3 - The package dependency from <PACKAGENAME>, if exists, are preserved
4- And, for control, you can do an rpm query thereafter on optflags.
For example
rpm -q --qf '%{optflags}' <PACKAGENAME>-opt and see if the optflags
are correct
hth

[devzero2000]

Thanks, but I don't think that will work for me, because I will have have
packages that require <PACKAGENAME>, and if I add -opt to the end of it, I
won't be able to swap out the unoptimized for the optimized without
ingoredeps, which I sometime do for debugging.

Try my example and your notice that, as i have told, there is not problem
for package that required PACKAGENAME. The procedure i have described is a
standard way to rename package without problem, e.g. without "ingoredeps".

I noticed the optflags field, but I'm concerned it won't be readily
apparent to the support engineers the way a change in the build number would
be (they may not know about "rpm -q --qf "). So I think I'll stick with my
idea of appending the _opt or _unopt to the end of "Release". It will have
some funny effects on update logic, but I can handle it.

Sure, it is an idea. But it not demostrate, because it is not merged in rpm
metadata, anything
at anywhone: it is just a "belive me because i have told you this thing"

JHMO, YMMV

Regards

An idea could be the following.
Let me call the package as <PKGNAME> for this example. I also suppose that
exists only, in a certain time, a single version of the package: the
"optimized" or the "notoptimized" installed and that i want the packages
distinguished not only for name but for some metadata informations. In
particular in rpm this metadata information is in the optflags tag.
First Package SPEC snip (e.g without optimization) (named as
PACKAGENAME-without-opt.spec)
--------------------------------------------------------------------------
%define optflags <what do you thinks are the flags without opt >
############################################
# %{expand:%%define optflags %( echo %optflags | sed 's/-g//g') }
#############################################
Name: <PACKAGENAME>-opt
Version : 1.0
Release: 1
Provides: <PACKAGENAME> = %{version}-%{release}
Obsoletes: <PACKAGENAME> <= %{version}
.
.
.
%build
###################
# use %configure or
# something like this
#
# CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ;
# CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ;
# FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ;
# ./configure ......
Second Package SPEC snip (e.g with optimization) (named
PACKAGENAME-opt.spec)
--------------------------------------------------------------------------
%define optflags <what do you thinks must go for opt flags >
############################################
# for example the default with -g always appended as this
# %{expand:%%define optflags %( echo "%optflags -g") }
#############################################
Name: <PACKAGENAME>-without-opt
Version : 1.0
Release: 1
Provides: <PACKAGENAME> = %{version}-%{release}
Obsoletes: <PACKAGENAME> <= %{version}
%build
# as before in the first package
Now you have
1- only a package installable : <PACKAGENAME>-opt or
<PACKAGENAME>-without-opt
2 - if you have <PACKANAME>-opt installed and you do : rpm -Uvh
<PACKAGENAME>-without-opt-1.0-1.<arch>.rpm
you have <PACKAGENAME>-without-opt installed and <PACKANAME>-opt
disinstalled : it is also true the reverse.
3 - The package dependency from <PACKAGENAME>, if exists, are preserved
4- And, for control, you can do an rpm query thereafter on optflags. For
example
rpm -q --qf '%{optflags}' <PACKAGENAME>-opt and see if the optflags are
correct
hth

[Carter Sanders]

_______________________________________________
Rpm-list mailing list
Rpm-***@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list