Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   RPM Package Manager (http://www.linux-archive.org/rpm-package-manager/)
-   -   Building optimized and non-optimized versions of the same rpm (http://www.linux-archive.org/rpm-package-manager/112324-building-optimized-non-optimized-versions-same-rpm.html)

Carter Sanders 06-24-2008 01:08 AM

Building optimized and non-optimized versions of the same rpm
 
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
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list

devzero2000 06-24-2008 12:45 PM

Building optimized and non-optimized versions of the same rpm
 
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 <general@cartersanders.com> 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

Rpm-list@redhat.com

https://www.redhat.com/mailman/listinfo/rpm-list



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

Carter Sanders 06-24-2008 06:37 PM

Building optimized and non-optimized versions of the same rpm
 
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.



devzero2000 wrote:

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


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

devzero2000 06-24-2008 08:30 PM

Building optimized and non-optimized versions of the same rpm
 
On Tue, Jun 24, 2008 at 8:37 PM, Carter Sanders <general@cartersanders.com> wrote:

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


devzero2000 wrote:


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




_______________________________________________

Rpm-list mailing list

Rpm-list@redhat.com

https://www.redhat.com/mailman/listinfo/rpm-list



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

Carter Sanders 06-24-2008 09:48 PM

Building optimized and non-optimized versions of the same rpm
 
Oh! I see. I overlooked the 'provides' stuff before. Thanks. I'll try
both ways.



devzero2000 wrote:
On Tue, Jun 24, 2008 at 8:37 PM, Carter Sanders <general@cartersanders.com>
wrote:


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



devzero2000 wrote:


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







_______________________________________________

Rpm-list mailing list

Rpm-list@redhat.com

https://www.redhat.com/mailman/listinfo/rpm-list









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






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


All times are GMT. The time now is 09:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.