[Fedora-packaging] [perl-Coro] Work-aroung missing libecb package on build-triggering host

[Paul Howarth]

On Tue, 23 Oct 2012 17:21:12 +0200
Petr Pisar <ppisar at redhat.com> wrote:

> On Tue, Oct 23, 2012 at 03:36:00PM +0100, Paul Howarth wrote:
> > On Tue, 23 Oct 2012 14:12:40 +0200
> > Petr Pisar <ppisar at redhat.com> wrote:
> > 
> > > On Tue, Oct 23, 2012 at 01:19:40PM +0200, Ralf Corsepius wrote:
> > > > On 10/22/2012 05:34 PM, Petr Pisar wrote:
> > > > >On Mon, Oct 22, 2012 at 10:14:25AM -0500, Rex Dieter wrote:
> > > > >>On 10/22/2012 10:06 AM, Ralf Corsepius wrote:
> > > > >>>On 10/22/2012 03:47 PM, Petr Pisar wrote:
> > > > >>>>--- a/perl-Coro.spec
> > > > >>>>+++ b/perl-Coro.spec
> > > > >>>>@@ -35,7 +35,7 @@ Requires:       perl(EV) >= 3
> > > > >>>>  Requires:       perl(Event) >= 1.08
> > > > >>>>  Requires:       perl(Guard) >= 0.5
> > > > >>>>  Requires:       perl(Storable) >= 2.15
> > > > >>>>-Provides:       bundled(libecb) = %(rpm -q libecb --qf
> > > > >>>>'%{VERSION}') +Provides:       bundled(libecb)%(rpm -q
> > > > >>>>libecb --qf ' = %{VERSION}'
> > > > >>>>2>/dev/null)
> > > > >>>
> > > > >>>I could be wrong, but IIRC, calling rpm inside of rpm specs
> > > > >>>is not allowed in Fedora.
> > > > >>>
> > > > >>>Apart of this, what you are doing is rendering your built
> > > > >>>non-deterministic - Another "strictly forbidden" item.
> > > > >>
> > > > >>Agreed.  What you're trying to say essentially is that the
> > > > >>bundled libecb version matches the system/non-bundled
> > > > >>version, which really doesn't make any sense.  I'd suggest
> > > > >>you simply remove the versioning (or list the real bundled
> > > > >>version some other way).
> > > > >>
> > > > >This is something like static library. Thus code gets frozen
> > > > >into the package at build-time. So I concluded it's good idea
> > > > >to know which version of the library the binary package
> > > > >incorporates.
> > > > >
> > > > >However if you think this is bad idea I will remove it.
> > > > 
> > > > Yes, I do - I am insisting on the rpm calls to be removed.
> > > > 
> > > Could you explain why calling rpm from spec file is bad idea?
> > 
> > The buildroot may have been populated by an rpm version outside a
> > chroot, with an incompatible version of libdb to the one in the
> > chroot, resulting in rpm within the chroot possibly being unable to
> > read the rpm database.
> > 
> Do you think boostrapping RPM is relevant for an high level perl
> package? I think it's quite unfortunate to disallow checking build
> system (especially if the spec code can deal with failing rpm as in
> my example).

It's nothing to do with bootstrapping rpm.

Builds are done using mock, which sets up the buildroot using the
buildsystem's version of rpm+libdb. This creates an RPM database in the
target chroot using the host's rpm.

Inside the buildroot, during the package build, the target's version of
rpm+libdb are used, which may be significantly older or newer than the
hosts's, depending on the target OS and the host OS. Hence calling rpm
within the spec file may fail because it may be unable to read the RPM
database, depending on how different the versions of rpm+libdb on the
host and target are.

Paul.