Re: [PATCH 1/1] linux-firmware: remove hard-coded paths

[Matthias Schiffer <mschiffer@universe-factory.net>]

[-- Attachment #1: Type: text/plain, Size: 4381 bytes --]

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.ray@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
>>
>>
>>
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]