Busybox-power 1.22.1power1 has been pushed to Fremantle's repositories. Thumb sources are sent to freemangordon for inclusion in the thumb repo. Enjoy!

A total of seven hotfixes appeared since the 1.22.0 release. These hotfixes are what's changed in busybox-power 1.22.1power1 vs the staging 1.22.0power1 release. Also see http://busybox.net/downloads/fixes-1.22.0/ and http://busybox.net/downloads/fixes-1.22.1/.

I still got issues pushing to Maemo's garage repo, so the sources (temporarily) reside at Github: https://github.com/iDont/busybox-power

Update: the updated busybox-power for Diablo has just been pushed to Diablo's repositories!

Sorry for the delayed response. The files section has been updated as you're used to with the new busybox-power release .

Hey, would it be unreasonable to add a "provides: less" or something along those lines to the packaging for busybox power, including all of the other utilities that busybox provides? Because I'm getting rather tired of having packages insist that they /must/ install packages that our busybox provides, for example the aforementioned less command. (Like really, why does the packaging for git insist that it needs less? And/or nano of all things? In all my life of using git, nano has never been necessary. Admittedly the latter is nothing to do with busybox, power or otherwise, I'm just lightly venting now... but that's a separate topic.)

I've received this request before . Here's my blatantly copy-pasted response:

Feel free to discuss this. I have no problem generating empty busybox-power-xyz packages that provide xyz and depend on busybox-power (or alternatively a single deb that provides them all). Let me know what you think about this!

Yeah, I know whom you mean

And frankly spoken I abandoned the bb-power provides.
I fully understood your answer/reasons. And agree to have bb-power not provide anything (as it often does not provide the full options).
I already was at the point to edit /var/lib/dpkg/status but it was a blind alley (and I reverted as the packages wanted to get updated as they recognized there is something different).
Best would be to correct/modify those packages in the repo(s) for which we know bb-power provides everything needed. But unfortunately this is sysiphos work (a lot of them do not have active maintainer anymore and one would need to take over maintainership. Or 'someone' with power rights would do this in repos itself)


I did not want to generate the work for iDont but maybe it is a good idea, those bb-provides packages (only for brave devel users).

Your reasoning, guys, is largely sound and I can't say I disagree all that much. In the long run I believe in choice first and convenience second, but sufficiently large convenience overrides insufficiently large choice. All I know is that, from a personal perspective, I don't want extra **** being installed when I don't need it just because someone else does, but at the same time, I don't want to impose inconvenience to others. (You know how asterisk depends on bash? Well, lately I've been tempted to recode anything in it that depends on bashisms into a straight bourne compatible shell just because I find the need to have bash on my N900s very irritating. But I digress.)

At the same time, I actually DO think that it's not a bad thing to do provides, and if it doesn't work, have users install the 'real' package instead. I maintain alpine for instance for those who don't remember, and I really feel tempted to add a 'provides nano' so that things don't install it when it's already an almost-compatible editor at least in the general usecase. But sure, maybe that's too confusing or whatever for other people, and it'll screw the tech-unsavvy more than the tech savvy ones. So I get it.

My suggestion is, do 'provides' for virtually feature-identical packages. Is there really anything to 'less' that our 'less' doesn't provide? Or, MORE fairly but harder to quantify, does busybox-power "less" provide the feature-set that a normal person can expect on a normal Unix/Linux system? If it meets either of these criteria, I think the provides should be right in the packaging of busybox-power. IF, on the otherhand, busybox's, say, tar, provides far less features than the GNU tar, then it shouldn't do a provides in the main packaging, and in that case we get around to discussing this.

I really like this idea. This is great in my opinion, it lets people have the best of my initial suggestion (and some of the bad parts), but it's a /chosen/ tradeoff and not imposed on anyone.

On that note, I was actually already thinking of doing this, and I think this is the path I'm going to take when I have the spare time to make some packages and push them to devel: 'fkdeps-xyz', where 'fkdeps' stands for either 'fake dependencies' or '[english cuss word beginning with 'f'] dependencies', depending on how you want to interpret it and how angry you are at unnecessary dependencies (for historical purposes, for me it meant the latter first, morphed into the former later), and 'xyz' is the name of the given package that that fkdeps package provides.

This way, we can have granular fake dependency-providing packages, in a generic name and not tied to any specific package, allowing packages that truly 'provide' a feature to only provide the ones they can clearly say they provide but also allowing users who don't want dependencies to be pulled in to....

...even better idea. I'm going to make a shell script called fkdeps (alternative name ideas welcome, I'm also considering the name "equi", since there's a Debian package called "equivs" which is a more feature-ful and more dependency-having tool of similar purpose), which will use the minimal tools it can (no dependencies on anything that isn't already on the N900 if at all possible) to create a fake deb package that provides the package name specified. I'll (someday) also give it a hard-fake option, to generate a package with the same name as the faked package, because that's the only way to fake a specific version and thus (because 'provides' is always unversioned) the only way to fulfill a versioned 'depends'. No fkdeps-* package bloat in the repos then.

Good talk.

I already thought about that, but dpkg -b passes --format=gnu parameter to tar, which busybox's one doesn't know. So you have to either install gnu-tar or binutils (for ar), or package something else with shell script. The irony here.

Damn it. Well, I suppose I COULD re-implement the relevant archiving compression algorithms in the shell... But that's just too much agony. Still, I for one would welcome one dependency if it let me remove many.

But besides that I guess it's fallback-to-fake-provide(s) packages. Having this script to automate the process to at least the point of having it ready to send to auto-builder would make it easier to send a bunch of fkdep-* packages to the repos.

Thought: The argument against doing 'provides' for existing packages that are more fully featured is made weaker by the fact that deb supports versioned dependencies, which can never be satisfied by a provides.

Actually, it looks like we have 'dpkg-deb' included in the stock N900.

Aaand the results are in, I can build a package with it (dpkg-deb, using a directory populated by my script) that it will then install. Tested 'Provides' property of course, works too. I'd say that's sufficient for the first version.

The script will be up in some repo somewhere within the hour if nothing derails me, and a properly deb-packaged version will be pushed to auto-builder not too far afterwords.

[EDIT: Actually, I should really test this on my completely-stock n900 before I say that with certainty, maybe dpkg-deb is doing exactly what you said]

[EDIT2: Yeah I should've realized that wasn't going to work from just what you said and what I know about dpkg. *Facepalm* False ray of hope that I raised in myself for no good reason there.]

[EDIT3: But wait, stock busybox does have an 'ar' command! It's just not symlinked out into its own name, but it can be invoked with 'busybox ar' - this seems more promising.]

[Edit 4: seems unusable because the busybox 'ar' that comes stock can only unpack, not pack)

So it turned out that the 'ar' 'common' format, which is what 'deb' files are, is trivial. It's essentially all of the files concatenated, with some metadata prepended to each file.

http://en.wikipedia.org/wiki/Ar_%28U...format_details

As a result, it is fairly straightforward to implement it using cat, printf/echo, ls+awk / wc to get the file size, and expr to do modulo-2 on the file size, because file entries have to be 2-byte aligned.

I was delayed in several ways today which kept me from getting this done sooner, but now I bring you: fkdep

Ta-da. It'll install packages with the name fkdep-[fake-provided-package-name], assuming it gets root permissions to do the actual install, or, if run as not-root, simply generate the .deb file and then leave it in the /tmp/fkdep-[whatever] directory for you to do what you want with. (For extra amusement factor, the fake packages self-license themselves under the wtfpl )

I'll make a proper announcement thread when I've had the chance to package it for our repos here.

[Edit: To be clear, this has, near as I've tested, literally no dependencies besides what is already installed on an N900 stock. I tested all of the individual commands through the stock busybox, BUT I have not yet tested on a truly-stock, no-CSSU-or-anything N900. It's on my todo list to do that, in the meantime if someone does find an unnoticed dependency let me know, though I'm fairly confident there are none.]

Nice idea (even too late for me )!
But sorry to let you know:

Of course I wanted to check created contents mnaually even if your code looked quite clean.
And you should open up an own thread to discuss further as this is going (a bit) offtopic now ...