On 01/04/2016 11:56 PM, Mark Hatle wrote: > 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..
Thanks for the explanation, I asked a similar question a few weeks ago
and didn't get a satisfactory answer about what fs-perms can do. I'll
rethink my approach for the merged-usr patchset.
So the remaining issue is how to conditionalize this. I'd like to find a
solution which doesn't require distros to define their own fs-perms when
they just want to use a merged /usr dir.
>
>> 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.
Is that discussion archived somewhere? I'm interested in the
argumentation. Do any non-OE distros have a similar feature?
>
> 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.
I didn't try yet as I didn't now that it is supposed to to that.
>
> --Mark
>
>> Matthias
>>
>>
>>
>
signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
