> -----Original Message----- > From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] > Sent: den 17 augusti 2017 12:53 > To: Mark Hatle <mark.ha...@windriver.com>; Richard Purdie > <richard.pur...@linuxfoundation.org>; openembedded- > c...@lists.openembedded.org > Cc: Peter Kjellerstedt <peter.kjellerst...@axis.com> > Subject: Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on > Pyro > > On 08/16/2017 06:37 PM, Mark Hatle wrote: > > Are there any examples? I was looking there and simply didn't see > > any. I saw the packaging for instance exercised python interfaces, > > version comparison tools, etc.. but nothing that built a > > recipe/package and then verified the contents were 'correct'. > > > > Ideally the test would be to fabricate something with a known set > > of file dependencies, produce a package from it and then verify > > that the package properly included those dependencies. > > > > I had looked at just picking some random library out of the deploy > > directory, and doing a pattern search on it's provides.. but I'm > > not sure that type of test would be very robust. > > How was this regression discovered in the first place? I guess that > some recipe used to build without error with rpm5, and stopped > building with rpm4. This is what you could test for: isolate the > problematic bit, remove everything else, and write a simple recipe(s) > that can be placed into meta-selftest. Then simply build those from > the selftest; if they build without error, you don't need to do more > sophisticated checks. > > Alex
The problem we have, which caused me to look into this, is: We unfortunately have a lot of unversioned libraries, e.g., "libfoo.so" instead of "libfoo.so.1.2.3". There is no problem building these (except we need to work around OE's default of putting *.so in ${PN}-dev rather than ${PN}). However, when rpm creates the packages for the applications linked with these libraries, it fails to automatically determine these runtime dependencies. However, since there are no errors, what then happens is that the image is created, lacking most of our libraries, which of course leads to the image failing to boot when applications cannot find the libraries they need... The reason this is not a problem with versioned libraries is that the code in OE has support for determining these and will feed that information to rpm. In hindsight, it would probably have been better if I looked at fixing that code to support unversioned libraries, but since rpm's automatic discovery of runtime dependencies worked in Morty, I thought it would be easiest to get the needed functionality back that was lost in the transition to dnf by fixing rpm... //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core