On 1/24/25 10:39 AM, Alexander Kanavin via lists.openembedded.org wrote:
I wonder if we can just drop /etc/shells altogether from base-files?
/etc/shells is used by pam as one of it's multiple validation steps. If the
shell is not listed there then remote login can be denied. So the existence of
/etc/shells is definitely required. The file doesn't need to come from
base-files (but usually should).
With that said, "something" needs to provide /bin/sh. Just dropping /bin/sh
from a shell, by itself, it's the right answer as there are ABSOLUTELY systems
out there where '/bin/bash' _is_ the only shell installed on the system.
Just like we have busybox only systems providing /bin/sh...
or dash based systems where it is the only thing providing /bin/sh...
I'm more inclined to say that base-files depending on /bin/sh is the error.
AFAIK nothing in base-files should require /bin/sh (or are there post-install
scripts?). Once that is resolved, then various POSIX /bin/sh providers can
each provide it -- using update-alternatives to have the 'best' matching
providing the right /bin/sh link. (This is why update-alternatives [in the past
at least] run directly and didn't require a shell to execute. I don't know that
we have the ability to do this with our multi-package support approach though.)
So essential install order may be something like:
base-files
libc (libraries only)
update-alternatives
<a shell>
- shell calls update-alternatives to register it as /bin/sh, as well as add
this as a valid shell to /etc/shells.
End result (for bash)
/bin/sh -> /bin/bash
/etc/shell contains:
/bin/sh
/bin/bash
(Note, circular dependencies for some base components have been considered
normal in the workstation world. They work around this by use the 'install' to
temporarily provide the /bin/sh and some other resources until they can be
installed into the chroot. This really isn't anything different from what
we're doing, we expect some host-system (native) items to be available in order
to populate the image.)
--Mark
Alex
On Fri 24. Jan 2025 at 16.26, Marek Vasut via lists.openembedded.org
<http://lists.openembedded.org> <[email protected]
<mailto:[email protected]>> wrote:
On 1/23/25 10:18 PM, Khem Raj wrote:
> On Thu, Jan 23, 2025 at 12:12 PM Marek Vasut via
> lists.openembedded.org <http://lists.openembedded.org>
<[email protected]
<mailto:[email protected]>> wrote:
>>
>> Remove /bin/sh from bash RPROVIDES as this has a side-effect which
>> confuses rpm package manager when also busybox provides /bin/sh and
>> base-files depend on /bin/sh . The problem is broken down below.
>>
>> First, bash depends on base-files and bash pkg_postinst must run
>> after base-files was installed, because it requires /etc/shells
>> provided by base-files to be in place.
>>
>> Second, base-files depends on /bin/sh, which is provided by either
>> bash or busybox in this case. This is the actual problem here, if
>> bash is selected as /bin/sh provider, then there is cyclic dependency
>> between bash and base-files, and that confuses dnf which may install
>> the packages in the wrong order, bash first and base-files second .
>>
>> To make this worse, if busybox is also /bin/sh provider, it can and
>> does happen that some systems pick busybox as the /bin/sh provider,
>> while others pick bash as the /bin/sh provider, and that cyclic
>> dependency does not always appear.
>>
>> Attempt to break this dependency, drop RPROVIDES /bin/sh from bash
>> recipe to always force base-files to pick /bin/sh from busybox .
>> (I am really unsure about this approach)
>>
>> Signed-off-by: Marek Vasut <[email protected] <mailto:[email protected]>>
>> ---
>> Cc: Alexander Kanavin <[email protected] <mailto:[email protected]>>
>> Cc: Alexandre Belloni <[email protected]
<mailto:[email protected]>>
>> Cc: Richard Purdie <[email protected]
<mailto:[email protected]>>
>> ---
>> meta/recipes-extended/bash/bash.inc | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-extended/bash/bash.inc
b/meta/recipes-extended/bash/bash.inc
>> index 634209c9115..6a061b8a612 100644
>> --- a/meta/recipes-extended/bash/bash.inc
>> +++ b/meta/recipes-extended/bash/bash.inc
>> @@ -134,4 +134,4 @@ FILES:${PN}-loadable += "${libdir}/bash/*"
>>
>> # Limit the RPROVIDES here to class target so that if usrmerge is
enabled for nativesdk, it does not
>> # include host system paths in /bin/
>> -RPROVIDES:${PN}:append:class-target = "
${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '/bin/sh /bin/bash', '',
d)}"
>> +RPROVIDES:${PN}:append:class-target = "
${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '/bin/bash', '', d)}"
>
> Does this now mean that system will always need busybox ?
The system will require some other /bin/sh provider than bash .
I suspect there will always be one , but maybe I am wrong and there are
systems without busybox and with bash only (probably yes) ?
> some distros
> may not want that and simply use
> other variants to fill in the shoes. I wonder if shell choice could be
> a distro option or image feature which can then
> help sort this out ?
I don't think this specific fix is the correct solution, I think what I
need to figure out is how to make sure base-files is installed before
bash, even if there is this cyclic dependency which confuses rpm/dnf
into installing the two packages in arbitrary order:
base-files -depends_on-> /bin/sh -depends_on-> bash (the /bin/sh provider)
bash -depends_on-> base-files
I still have to check the input from Martin Jansa , there was some hint
which might be the better fix for this.
Any ideas ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#210245):
https://lists.openembedded.org/g/openembedded-core/message/210245
Mute This Topic: https://lists.openembedded.org/mt/110778651/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
