[SOLUTION] Fwd: automatically modifying scriptlets (included files) at package build time

[Eddy Petrișor]

Hello,

I just want to let you know I discovered the solution to my problem.


Is as simple as adding something after the %setup command in the %prep section:

Index: SPECS/common.spec
===================================================================
--- SPECS/common.spec   (revision 2033)
+++ SPECS/common.spec   (revision 2034)
@@ -29,6 +29,9 @@

 %prep
 %setup -n common
+. common.inf && export THISVER="`echo "$VERS.$SUBVERS.$RELEASE" | tr -s '.'`"
+sed -i "s#^THISVER=.*#THISVER=$THISVER#" %{SOURCE101}
+sed -i "s#^THISVER=.*#THISVER=$THISVER#" %{SOURCE102}

 %install



Forwarded my message that I accidentally sent only to Horst.

---------- Forwarded message ----------
From: Eddy Petrișor <eddy.petrisor at gmail.com>
Date: 18 Mar 2008 10:21
Subject: Re: automatically modifying scriptlets (included files) at
package build time
To: "Horst H. von Brand" <vonbrand at inf.utfsm.cl>


Horst H. von Brand wrote:

> Eddy Petrior <eddy.petrisor at gmail.com> wrote:
 >>         I would like to know if there is a way to do this:
 >>
 >>         <eddyp_work>    is there a way to generate the maintainer
scripts out
 >>         of .in scriptlets, at build time (i.e. use templates for
the maintainer
 >>         scriptlets and run some tool to generate the ones that
should end up in
 >>         the package)
 >>         <f13>   eddyp_work: that gets in the way of scripted
rebuilds and such
 >>         <eddyp_work>    f13: why would it?
 >>         <f13>   eddyp_work: because scripts expect a .spec file,
not a .spec.in
 >>         <eddyp_work>    f13: spec files can use includes....
 >>         <eddyp_work>    f13: I was thinking of generating those before the
 >>         package build; something like a configure stage, but for the package
 >>         itself
 >>         <f13>   eddyp_work: *shrug* would be worth posting to
fedora-devel-list
 >>         with an example of what you want to do
 >>         <eddyp_work>    f13: debian can do that in the debian/rules file
 >>         <eddyp_work>    f13: I want to be able to have a variable set in the
 >>         scripts with some contents that is got from the source
 >>         <eddyp_work>    s/scripts/maintainer scriptlets/
 >>
 >>
 >>
 >>         The main idea is that I am maintaing the packages for our antivirus
 >>         product and we have some automated builder for the packages and the
 >>         upstream part of the packages.
 >>
 >>         There can be multiple releases/day of the upstream package and
 >>         the rpm packages are updated automatically to follow the
 >>         upstream packages' versions.
 >>
 >>         Now, here follows the tricky part, so please pay attention:
 >>         the upstream package itself contains some file that specifies
 >>         the version of the package (we needed this to be able to tell
 >>         which version over which version we're upgrading/installing,
 >>         since rpm doesn't pass this information to the {pre,post}{,rm}
 >>         scripts).
 >
 > Can't you use the %{version} "variable" for this?


No, I already said that the %{version} can be different from what the
file containing the version
 (e.g. right before the release when the contained files are saying
"final" while the tarball version
 is still "release candidate..." (or "prerelease", if you prefer).


 >>         (I am using includes already and have the scriptlets separated into
 >>         scripts.)
 >>
 >>         So the thing is that the file in the package can have a
 >>         different version than the one of the package or the tarball,
 >>         so the scripts need to use/know the version that is placed in
 >>         the files themselves.
 >
 > Hum... perhaps the file that is changing should be another RPM? I.e.,
 > one "package" and a "data" one, like ClamAV does?


No, because that file indicates the version of the package itself
which tells us how we're going to
 do the upgrade, when a newer version appears.


 >>         That's why I need some kind of configuration step of the
 >>         package that can be always ran after the package was unpacked,
 >>         but before the package is generated so I can generate the
 >>         scriptlets with the filled information so the upgrade part
 >>         works correctly.
 >
 > If I understand correctly, you need to create an RPM to update from
 > version 2.3.45 to 2.3.46? Can't be done. No way to know beforehand what
 > the user has installed/updated (if anything). In any case, such a thing


Yes, it can be done, we've been doing this until now, but the version
detection mechanism was
 present in some external scripts, and now we're moving them inside.

 Also, it *is* possible to know what was installed, since the files I
was referring to contain the
 version of the product, so we work around the limitation of rpm which
doesn't provide the old
 version by sourcing that info from the file already present on the disk.


 > is probably fragile, better delete all and install anew (this is what
 > RPM would do, in any case).


No, it doesn't do exactly that. Files which are not part of the
package (like configuration files)
 are not touched, and these files are the object of the upgrade.


 --
 Regards,
 EddyP
 =============================================
 "Imagination is more important than knowledge" A.Einstein



-- 
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein