On 01/04/2016 05:32 PM, Mark Hatle wrote: > On 1/4/16 10:11 AM, Matthias Schiffer wrote: >> On 01/04/2016 02:14 PM, Ian Ray wrote: >>> The recipe uses hard-coded paths (specifically /lib) in do_install >>> and in FILES, however on a merged /usr system this directory might >>> not exist. Prefer base_libdir. >>> >>> Signed-off-by: Ian Ray <ian....@ge.com> >>> --- >> >> This should use nonarch_base_libdir, base_libdir defaults to /lib64 on >> ppc64, which is not where the firmware is expected. >> > > At a minimum, I would agree nonarch_base_libdir, however.. > > I believe that the kernel loader/modules/tools themselves actually have '/lib' > hard coded into them. This is the reason why /lib/firmware was used and not > one > of the variables. > > This is one of the cases were /lib is actually correct, since that is what the > system is expecting. We can make some kind of accommodation for systems where > /lib -> /usr/lib... but that should be done inside of the filesystem setup > processing and not the package itself. (I'm referring to the > 'meta/files/fs-perms.txt' file. > > --Mark >
There seem to be some intresting ideas going around about what can or should be done via fs-perms.txt... AFAICT, fs-perms.txt can't move around files, so moving files form /lib to /usr/lib must be done in the package recipes themselves. (In my opinion, fs-perms.txt is a bad hack for broken recipes that shouldn't exist anyways, but that's another discussion) I think if a distro config changes any of the base paths ({nonarch_,}base_libdir, base_{,s}bindir), *all* packages should respect this. It's the distro's reponsiblity to create symlinks so everything is found again at the expected paths (other examples for such hardcoded paths: /bin/sh; the dynamic linker). See also my patchset I submitted to this mailing list, which introduces a distro feature to have such symlinks created by base-files. Matthias
signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core