I'm right in thinking that it's bad to call rpm from rpmbuild?
During my find-requires script, I need to get the exact name-version-release of the ocaml compiler. Obviously the compiler knows its name & version, but not its release.
At the moment I'm doing:
if [ -n "$emit_compiler_version" ]; then # Every OCaml program depends on the precise version of the # compiler which was used to compile it. rpm -q --qf '%{NAME} = %{VERSION}-%{RELEASE}\n' ocaml fi
but if calling rpm like this is bad, I'm wondering how to fix it. Best way I can see to do this is to store the name-version-release of the compiler in a special file in the ocaml RPM, something like:
/usr/lib64/ocaml/fedora-ocaml-release
which would contain something like 3.09.0-3 or whatever, then the script can be changed to cat this file.
What do people think?
Rich.
Richard W.M. Jones wrote:
I'm right in thinking that it's bad to call rpm from rpmbuild?
Yes.
but if calling rpm like this is bad, I'm wondering how to fix it. Best way I can see to do this is to store the name-version-release of the compiler in a special file in the ocaml RPM, something like:
/usr/lib64/ocaml/fedora-ocaml-release
which would contain something like 3.09.0-3 or whatever, then the script can be changed to cat this file.
This is workable, or possibly use pkg-config (as was proposed recently with emacs stuff).
-- Rex
On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote:
Richard W.M. Jones wrote:
I'm right in thinking that it's bad to call rpm from rpmbuild?
Yes.
But weren't recursive rpm calls fixed many, many years ago, so that this is fine to use since ??? (hopefully including RHEL3)?
Axel Thimm wrote:
On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote:
Richard W.M. Jones wrote:
I'm right in thinking that it's bad to call rpm from rpmbuild?
Yes.
But weren't recursive rpm calls fixed many, many years ago, so that this is fine to use since ??? (hopefully including RHEL3)?
Stop the heresy, you'll raise spot's blood-pressure... :)
In practice, it may or may not work (not more often than not, in chroot'd buildroots), but it's best to simply say "just don't do it".
-- Rex
On Tue, 2007-06-05 at 10:14 -0500, Rex Dieter wrote:
Axel Thimm wrote:
On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote:
Richard W.M. Jones wrote:
I'm right in thinking that it's bad to call rpm from rpmbuild?
Yes.
But weren't recursive rpm calls fixed many, many years ago, so that this is fine to use since ??? (hopefully including RHEL3)?
Stop the heresy, you'll raise spot's blood-pressure... :)
In practice, it may or may not work (not more often than not, in chroot'd buildroots), but it's best to simply say "just don't do it".
FWIW, I asked Panu about this, and this was his reply:
For the casual "rpmbuild -ba foo.spec" usage, querying from within a build is what I consider "mostly harmless". However in the Fedora context, where packages will be built within a chroot with no guarantees about the rpm version outside vs inside the chroot, it WILL break sooner or later due to db environment mismatch. Eg if RHEL 4 was used as the build host, in FC[567] (or thereabouts) chroot the query would fail.
Mock *could* of course clear the environment (the infamous 'rm -f /var/lib/rpm/__*') before entering the chroot and after exiting it to avoid the issue. Or one could configure them to use DB_PRIVATE locking, but lets not go there... :)
*****
So, basically, don't do it. We can't be sure it is safe, or predictable, and we know there are at least some failure cases.
~spot, breathing calmly, slowly
On Tue, Jun 05, 2007 at 10:14:20AM -0500, Tom spot Callaway wrote:
On Tue, 2007-06-05 at 10:14 -0500, Rex Dieter wrote:
Axel Thimm wrote:
On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote:
Richard W.M. Jones wrote:
I'm right in thinking that it's bad to call rpm from rpmbuild?
Yes.
But weren't recursive rpm calls fixed many, many years ago, so that this is fine to use since ??? (hopefully including RHEL3)?
Stop the heresy, you'll raise spot's blood-pressure... :)
In practice, it may or may not work (not more often than not, in chroot'd buildroots), but it's best to simply say "just don't do it".
FWIW, I asked Panu about this, and this was his reply:
For the casual "rpmbuild -ba foo.spec" usage, querying from within a build is what I consider "mostly harmless". However in the Fedora context, where packages will be built within a chroot with no guarantees about the rpm version outside vs inside the chroot, it WILL break sooner or later due to db environment mismatch. Eg if RHEL 4 was used as the build host, in FC[567] (or thereabouts) chroot the query would fail.
Mock *could* of course clear the environment (the infamous 'rm -f /var/lib/rpm/__*') before entering the chroot and after exiting it to avoid the issue. Or one could configure them to use DB_PRIVATE locking, but lets not go there... :)
Yes, that's true, which is why I use a common rpm version both outside and inside the chroots :)
So, basically, don't do it. We can't be sure it is safe, or predictable, and we know there are at least some failure cases.
I've been using is for several years though for the same reason as Richard: I needed to find the exact package evr for some builds, mostly in order to create strict dependencies.
But I've been cheating, so I never got into troubles ever. :)
packaging@lists.fedoraproject.org