[4.0.1.45] BASH regression / Request to include it as standard again

General
#1

Dear Jolla Team, please add bash as standard shell again into SFOS.

In the meanwhile (NO WARRANTY!):

As root download “gnu-bash” with pkcon. Deinstall busybox-symlinks-bash forcely.
Install gnu-bash-5.0.18+git1-1.2.1.jolla.armv7hl.rpm with rpm manually.
The result will be - working custom scripts again.

Version:

# bash -version|head -1
GNU bash, version 5.0.18(1)-release (armv7l-unknown-linux-gnueabi)

Conflicting packages

# ls -1 *rpm
busybox-symlinks-bash-1.31.0+git17-1.3.5.jolla.armv7hl.rpm
gnu-bash-5.0.18+git1-1.2.1.jolla.armv7hl.rpm
12 Likes
Pass from storeman
ToeTerm support thread
#2

Hi leon
Simply removing busybox-symlinks-bash replaces busybox-bash by bash-5. No need to install gnu-bash-5.0.18+git1-1.2.1.jolla.armv7hl.rpm

4 Likes
.bashrc does not load automaticly after update from SFOS 3.4 to 4.1.28
#3

Hello,

I still dont get it why they switched to busybox. That’s a mistake.

Bring back the native bash by default !

3 Likes
#4

@ced117, this is not mistake, it is a positive consequence of a nice strategy change at Jolla:
As denoted in the IRC community meeting logs, they ceased to avoid GPLv3 software in general.
Instead they started distributing GPLv3 software as optional RPMs for SailfishOS, i.e. what formerly was (until SailfishOS 2.2.1) in the mer-tools repository. Now (since SailfishOS 4) only the RPMs for the basic SailfishOS (i.e., which may be installed by default) are still kept free of GPLv3 software.

This change in strategy allowed Jolla to update the historic, last GPLv2 version of bash (v3.2.57) to a recent bash v5, but only as an optional RPM. At the same time a recent busybox version of ash is installed by default, along with a symlink which calls ash in its (limited) bash compatibility mode.
RPMs at Openreps can simply conflict to busybox-symlink-bash in their spec file and bash will be automatically installed, if it was not installed before. But preferably their shell scripts shall be freed of BASHisms.
Users can simply uninstall the busybox-symlink-bash RPM and bash will be installed, if it was not installed before. Users not capable of accomplishing that do definitely not need a bash for interactive use.

TL;DR
While this may break some apps for now, it is easy to adapt them.
Much more importantly, Jolla’s license strategy change is a small, but relevant step forward for Jolla and SailfishOS.

16 Likes
#6

Why is GPL3 free core system a positive movement?

#7

This is arguable: on one side, FREEdom; on the other side, more industry interest.

Anyhow, if I understand correctly the change here is not “the core system has become GPL3-free”; it is "the core system is still GPL3-free, but now it is easier to install GPL3 apps because you don’t need to add repos.

2 Likes
#8

My understanding is similar to what @fph stated above: GPLv3 has some additional restrictions related to commercial use cases that GPLv2 doesn’t have. Eventhough they have similar names, these additions in GPLv3 leads to you not being able to mix and match GPLv2 and GPLv3 code/libs/tools in same project. I assume these commercial restrictions might risk Jolla’s commercial operating model and they want to keep the core elements GPLv2.

#9

The mix could be the problem. One can not mix GPL2 and GPL3. I am involved in GPL2 project FreeCAD. We do no include GPL3 software, because than we would need to relicense everything on GPL3. That might be the reason for GPL3 free Sailfish core too.

#10

Maybe inside a single project, but most Linux distros include both GPL2 software (case in point: the kernel, git) and GPL3 software (case in point: modern versions of bash) and nothing exploded; so that alone is not the reason.

#11

Do I understand it correctly? Recap: from SFOS3.4 to SFOS4.0 the bash package was updated from version 3 (GPLv2) to version 5 (GPLv3). And that is the reason why bash can not be in the compose of the SFOS flashable image? My understanding is that if a projects “binds” to the GPLv3 licensed software, then the problems arise (linking, shared opbjects etc).
https://www.gnu.org/licenses/gpl-3.0-standalone.html#section1
but thats not the case for SFOS/bash. SFOS already proved with SFOS4 that can run without bash. So including it like other distros should not be a problem.

1 Like
#12

Not a problem for you and me :slight_smile:

The Business customers of Jolla have a different opinion and they bring in the most money. In the meeting-log I remember reading that not having GPL3 software in the base image will lead to more paying customers. I think the meeting log was quite clear on 08:06:31.

I do understand that reality is not always like we want it to be. I am very happy that for some software there is now a way forward. I prefer this situation over staying stuck on bash v3. Packages that really need it can still have it as a dependency.

2 Likes
#13

Users can simply uninstall the busybox-symlink-bash RPM

What is prefered way to remove the symlink? Just removing the link with rm command or deinstall the rpm with rpm command or whatever?

cheers bernd

1 Like
#14

preferred way is to use pkcon or zypper.

not rm, not rpm.

3 Likes
#15

ahh ok, sorry I have been using apt-get and dpkg for twenty years. I just thought the command would be rpm. No idea why … :sunglasses:

I will try pkcon. This is installed. Anything I need to know?

#16

Haven’t tested but I would assume just plain pkcon remove busybox-symlinks-bash should do the trick. If it says gives some error and lists the package name with exact version, try again with the exact name and it probably works this time.

3 Likes
#17

pkcon remove busybox-symlinks-bash worked great

4 Likes
Pass from storeman
#18

By my own experience, busybox ash scripts are running without problem in gnu bash but not viceversa. Therfore gnu bash should be considered a super-set in terms of scripting capabilites compared to near complete busybox ash.

Because of this, reverting back the default shell to gnu bash should not create - presumably - no any problem unless very peculiar corner cases are triggered. However, those applications that need gnu bash should call it expressely:

  • scripts: with the proper shebang #/bin/bash or #/usr/bin/env bash

  • executable: forking or childing with /bin/bash

However, this sane approch fails if the busybox or a package installed in /bin/bash a link to busybox executable. This should be considered a mistake, in any system that can potentially host the gnu bash or it for which with gnu bash was a long-term referencing shell interpreter.

Thus regression is a correctly chosen word in the title of this post, IMHO.

Issues related to qCommand found on 4.5.0.19

Creating an icon for executing a command, it happens that:

  • the command spawn an opening application that stays on the home screen much longer the comand completed when the command complete almost immediately and sucessfully even if kill -9 $$ or kill -9 $PPID has been added at the end. Probably is about a timeout in the apps launcher.

  • a command icon created by qCommand cannot be deleted as any other application, Moreover, it is not possible to remove it even if the original script in qCommand is deleted but this makes sense because I may want remove the command without removing the icon, and viceversa.

I hope this helps, R-

UPDATE

I add the suggestion to restore the /bin/bash symlink to the original bash shell in my quick start guide in hints and tips section. :blush:

1 Like
A collection of tasks and a request for changes