[OE-core] [PATCH 11/11] package.bbclass: Restore functionality to detect RPM dependencies

Peter Kjellerstedt peter.kjellerstedt at axis.com
Thu Jun 15 14:19:14 UTC 2017


> -----Original Message-----
> From: Alexander Kanavin [mailto:alexander.kanavin at linux.intel.com]
> Sent: den 15 juni 2017 16:03
> To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>; openembedded-
> core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 11/11] package.bbclass: Restore
> functionality to detect RPM dependencies
> 
> On 06/15/2017 04:53 PM, Peter Kjellerstedt wrote:
> > During the transition to dnf and rpm4, the functionality to
> > automatically make RPM determine dependencies was lost.
> >
> > Before the transition, an OE specific tool called rpmdeps-oecore had
> > been added to the rpm suit. It was based on the rpmdeps tool that is
> > part of rpm. For each file specified on its command line, it would
> > output the provides and requires that RPM could determine.
> >
> > During the transition to rpm4, rpmdeps-oecore was replaced with the
> > standard rpmdeps. However, what no one noticed was that unless
> rpmdeps
> > is given options, e.g., -P or -R, to tell it what it should output,
> it
> > will not output anything. Thus, it would do all the work to determine
> > the requirements, but would keep silent about it. And since no output
> > from rpmdeps is expected unless there are requirements, there were no
> > warnings indicating that everything was not working as expected.
> >
> > Porting the old rpmdeps-oecore to work with rpm4 is not really
> > possible since it relied on being able to access internals of RPM
> that
> > are no longer available. However, it turned out that rpmdeps had a
> > debug option, --rpmfcdebug, that would output exactly the information
> > that we need, albeit in a different format and to stderr. To make
> this
> > usable, rpmdeps has now received a new option, --alldeps, which sends
> > the information we need to stdout.
> 
> I'd like you to address my previous comment: how do you ensure this will
> continue to work going forward? Is it taken into use by default, and if
> it breaks, will we notice?
> 
> Alex

Yes, once the last commit that changes package.bbclass is integrated, it 
will be activated for all builds that use RPM. And given how red the 
autobuilders got when RP did it the first time, I do not think there is 
any chance we will miss problems due to it...

I do agree that some kind of tests for this would probably be good. 
However, I do not have any experience with the oe-selftests, and how to 
implement some tests for this, and I am pressed for time as I go on 
summer vacation next Friday and would very much like for this to be 
fixed before then. Especially as we need these changes to make it into 
Pyro as well...

//Peter




More information about the Openembedded-core mailing list