On 1/4/16 4:26 PM, Matthias Schiffer wrote:
> 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)
Since I wrote fs-perms.txt, I'll explain the purpose. Individual packages don't
know if something is a directory, symbolic link, or what owner/group/permissions
a system level directory should be set to.
The entire purpose of it is to declare a common set of -system- directories.
(Packages/layers can amend and override this as necessary to add their own
system directories.)
FYI System directories are things like /usr/bin. Having every package in the
system need to define /usr/bin as a directory with an owner/group of root:root
and permission of 0755 is a REALLY bad practice.. but putting this knowledge
into a single file that synchronizes everything is very practical.
When the system level directories are mapped to symlinks.. the case where
everyone is trying to folks /usr -> / or /bin -> /usr/bin.. then it can
AUTOMATICALLY map and move the files in these places..
> 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.
When this was written it was heavily argued against this knowledge being in
base-files or base-dirs (suggested at the time) packages.
Defining a base setup, and then using a synchronization pass using the
fs-perms.txt was the way to go.
Note, fs-perms process is absolutely supposed to move files around -if- a
symlink is generated.. i.e.:
/lib -> /usr/lib
if you write to /lib/firmware, the code is supposed to see the directory of
'/lib', create a new /usr/lib (set perms properly) and move the contents if /lib
to /usr/lib, then replace the directory with a symbolic link.
If it's NOT doing that, lets fix it.
--Mark
> Matthias
>
>
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
