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 |
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 |
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 |
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 |
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 12:40 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.