Thanks Mentalist Traceur, reinob, and peterleinchen for the productive discussion. If any of you (or others) find the time to have a look at BusyBox' sources, that'd be much appreciated .

BusyBox indeed keeps its history in memory and writes it out upon shell closure. The writing out process goes as I briefly described earlier. BusyBox keeps its history in memory in a line_input_t struct (see include/libbb.h), and only assigns relevant file pointers in load_history() and save_history() (see libbb/lineedit.c).

I'll be out of the country tomorrow for a few weeks with only very limited or no internet connection available at all. Therefore, I probably won't be able to follow TMO during that time. Just to let you know. But by all means, don't hesitate to continue discussion .

I've found some spare time


However, it isn't finished just yet. The packaging still needs to be updated, as Harmattan requires some special attention regarding messing with system binaries (with kind regards from aegis). Then everything still has to be tested. Anyway, when it's done you'll be able to install and use it just like busybox-power on Fremantle.

You can upload the package to MAG's repository for applications that require Inception.

Thanks for the suggestion. However, busybox-power itself won't need to be incepted. Nokia deployed, just like in Fremantle, a metapackage in Harmattan that depends on specific versions of system packages, including busybox.
That means we have to replace /bin/busybox in busybox-power's postinst to not break any (C)SSU updates while still being able to provide busybox-power updates via community repositories, just like busybox-power did in Fremantle.

Busybox-power for Harmattan will depend on inception/opensh and aegisctl though. It requires either inception (more specifically: ariadne) or opensh to replace /bin/busybox, update aegis' refhashlist, and resign the list.

Aegisctl is required to temporarily allow untrusted binaries to be executed. Aegis loads all reference hashes in the kernel when booting your device. This means that during the period between replacing /bin/busybox and the next reboot, access to /bin/busybox would otherwise be denied for root. That's highly undesirable of course, hence the dependency on aegisctl.

A general notice: next CSSU release will ship a new version of Maemo's default BusyBox; one with portait mode support. This means that your /bin/busybox will be changed to CSSU's version.

Simply reinstalling busybox-power (either graphically or via the terminal) will get you busybox-power again. I'll make sure to incorporate all patches from CSSU's busybox in busybox-power so you won't miss out on any new functionality or bugfixes.

There is one important detail, however! If you've made manual modifications to Maemo's critical scripts (e.g. /sbin/preinit) that made those dependant on busybox-power during boottime, you will have to revert those prior to updating CSSU. Otherwise you could risk a boot loop.

Lastly, upon removal or reinstallation of busybox-power, busybox-power will detect and warn you if /bin/busybox has been changed. You can safely ignore this warning, as we know what has caused it (CSSU update changing /bin/busybox).

The above message will be included in the first post of this thread.

Edit: I've updated the warning message mentioned above in busybox-power 1.20.2power1. It now states why /bin/busybox could've been modified, and explicitly mentions CSSU as a possible cause. Just to comfort users who may have missed this post .

It's a pity, that CSSU doesn't use it as great opportunity to incorporate busybox-power. Not much sense in upgrading busybox with portrait support *only*.

/Estel

replacing busybox by busybox-power eats rare precious space in rootfs (due to larger binary size of busybox-power), since busybox is needed during early boot and thus has to live in rootfs. I.E. it can't get optified.
Busybox-power however doesn't - by default - bring anything new that might justify indiscriminate waste of rootfs space for it, on all CSSU installs.
It's absolutely reasonable to keep busybox-power optional for those users who think they need it and want to accept the rootfs penalty it comes with.

/j

We are talking about 500k !
Not really meesing up rootfs space, or?

I, personally, can not imagine "living" with standard busybox and its limitations anymore. But can also live with ""optional"" installation, but would/do see this package as an (default) enhancement, also to CSSU.

Does the CSSU busybox have the fix for the non-persistent history bug? If not were should it be reported?

Long version: default maemo busybox forgets history arbitrarily. This was not fixed until some recent version of cssu and when I asked I was told to install busybox-power which indeed does not suffer from this bug. I have b-p ever since and I don't know if this bug has been fixed in CSSU.

False - busybox power brings tons of upstream bugfixes and optimizations. Obviously, without breaking anything

Also, it's funny, that You started to care for few kb in root space - then, you should be major advocate of bringing thumb2 support to CSSU, as it saved *much* root space.

Now, waiting for You to bring "compatibility with scripts relying on bugs" argument, that You have used on IRC...

/Estel