automatically modifying scriptlets (included files) at package build time
Horst H. von Brand
vonbrand at inf.utfsm.cl
Mon Mar 17 20:05:30 UTC 2008
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?
> (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?
> 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
is probably fragile, better delete all and install anew (this is what
RPM would do, in any case).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
More information about the devel
mailing list