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

[Petr Pisar]

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).

-- Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/perl-devel/attachments/20121023/f79675a8/attachment.sig>