[OE-core] [PATCH v2 2/3] base-files: create ${base_bindir} etc. instead of /bin, /sbin and /lib

[Matthias Schiffer]

On 01/05/2016 01:16 AM, Mark Hatle wrote:
> On 1/4/16 5:46 PM, Matthias Schiffer wrote:
>> On 01/04/2016 11:59 PM, Mark Hatle wrote:
>>> On 1/2/16 5:53 PM, Matthias Schiffer wrote:
>>>> These directories conflict with the symlinks created for merged-usr setups.
>>>>
>>>> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
>>>> ---
>>>> v2: create both ${base_libdir} and ${nonarch_base_libdir}
>>>>
>>>>  meta/recipes-core/base-files/base-files_3.0.14.bb | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb b/meta/recipes-core/base-files/base-files_3.0.14.bb
>>>> index b71d5c5..2af7ecd 100644
>>>> --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
>>>> +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
>>>> @@ -33,8 +33,8 @@ INHIBIT_DEFAULT_DEPS = "1"
>>>>  docdir_append = "/${P}"
>>>>  dirs1777 = "/tmp ${localstatedir}/volatile/tmp"
>>>>  dirs2775 = ""
>>>> -dirs755 = "/bin /boot /dev ${sysconfdir} ${sysconfdir}/default \
>>>> -           ${sysconfdir}/skel /lib /mnt /proc ${ROOT_HOME} /run /sbin \
>>>> +dirs755 = "${base_bindir} /boot /dev ${sysconfdir} ${sysconfdir}/default \
>>>> +           ${sysconfdir}/skel ${base_libdir} ${nonarch_base_libdir} /mnt /proc ${ROOT_HOME} /run ${base_sbindir} \
>>>>             ${prefix} ${bindir} ${docdir} /usr/games ${includedir} \
>>>>             ${libdir} ${sbindir} ${datadir} \
>>>>             ${datadir}/common-licenses ${datadir}/dict ${infodir} \
>>>>
>>>
>>> I agree this new set looks correct.. but I'd like to see the corresponding
>>> change to fs-perms that sets the permissions and such for each of these new
>>> locations.
>>>
>>> --Mark
>>>
>>
>> The current meta/files/fs-perms.txt doesn't mention any of /bin, /sbin
>> or /lib, and seemingly never did. I guess they could be added, but that
>> could also be done in a separate patch (and as I mentioned in another
>> mail, I'm not exactly a fan of the fs-perms concept, so I don't really
>> care.)
> 
> Actually it does:
> 
> # Note: all standard config directories are automatically assigned "0755 root
> root false - - -"
> 
> Actual definition is buried in the code itself, meta/classes/package.bbclass:
> 
>     # By default all of the standard directories specified in
>     # bitbake.conf will get 0755 root:root.
>     target_path_vars = [    'base_prefix',
>                 'prefix',
>                 'exec_prefix',
>                 'base_bindir',
>                 'base_sbindir',
>                 'base_libdir',
>                 'datadir',
>                 'sysconfdir',
>                 'servicedir',
>                 'sharedstatedir',
>                 'localstatedir',
>                 'infodir',
>                 'mandir',
>                 'docdir',
>                 'bindir',
>                 'sbindir',
>                 'libexecdir',
>                 'libdir',
>                 'includedir',
>                 'oldincludedir' ]
> 
> The problem is people have added 'additional' standard directories since that
> time and have NOT updated the table.
> 
> So likely the following needs to be added (based on the current bitbake.conf):
> 
> nonarch_base_libdir
> systemd_unitdir
> systemd_system_unitdir
> nonarch_libdir
> systemd_user_unitdir
> 
> 
> As mentioned before.. the problem being solved is: If you don't have the table
> of system directories and permission.. and you build a package that uses a
> standard system directory.. what owner/group/permission does that directory get?
> 
> Answer? depends on the package, package manager and other misc things.. this is
> a really really bad case on non-deterministic behavior.  If we run through a
> table of operations (this internal table and the one in the fs-perms.txt and
> other files, if added) then we can synchronize -all- packages in a build with
> the configured system setup.
> 
> Note, with the way this was designed.. if /bin should NOT be a directory, the
> fs-perms.txt (or additional files provided by a configuration) can simply
> declare it as a symlink and the original entry goes away.
> 
> A distribution definition is a combination of the distro config file, matching
> fs-perms settings, and other associated files.  People miss the fs-perms, I
> don't know if they don't realize it's there and why it's there or if they assume
> it's a one size fits all default configuration.  (The default does fit many
> configurations, but not all....)
> 
> --Mark
> 
> 
>> Matthias
>>
> 

Okay, I've thought a bit more about this now.

* I'm fine with fs-perms.txt fixing up permissions, that is actually a
good idea (I haven't yet researched though if any non-OE distros have a
similar feature.)


* I agree with you that having a base package like base-files create all
symlinks defined in fs-perms.txt would make sense.

I'd like to send a v3 of my patch which does that, thus dropping the
distro feature / package config again. If such an approach was rejected
a few years ago, I'd like to get a bit more input on this first, I
couldn't find that particular discussion in the archives.

(I'd also like to add some documentation about fs-perms.txt as comments
in the base-files recipe, so people who look into adjusting the
base-files package will find it.)


* I stand by my opinion that moving files automatically is a bad idea,
and the FILES issue mentioned in the other thread further backs my point
(besides that issue, I've mentioned relative symlinks and relative paths
in general as problems that can break packages when their files are moved).

My proposal would be to change the fs-perms.txt handling to only check
if nothing conflicts with default symlinks, but not to create or move
anything. This is another point I'd like to get more input on.


Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160110/bc246492/attachment-0002.sig>