Re: Building optimized and non-optimized versions of the same rpm

devzero2000 <[email protected]> Tue, 24 Jun 2008 14:45:55 +0200
Newsgroups gmane.linux.redhat.rpm.general
Message-ID <[email protected]>
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

On Tue, Jun 24, 2008 at 3:08 AM, Carter Sanders <[email protected]>
wrote:

> 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
> [email protected]
> https://www.redhat.com/mailman/listinfo/rpm-list
>

_______________________________________________
Rpm-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rpm-list