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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
