On 1/2/08, Eero Tamminen <[EMAIL PROTECTED]> wrote: >The maintenance wouldn't be a problem. Then those packages can come >directly from Debian. Also, then trying to install a properly working >replacement for a buggy/incomplete Busybox functionality doesn't mean >that one would need to remove first Busybox and half the device software >depending on what else Busybox provides.
Shouldn't need to remove any device software if REPLACES is used and if any dependencies in the system respect treat the replacement as equivalent to the original. The only dangerous thing is that dpkg scripts presumably rely on busybox being there: at some point during install the old busybox is replaced by the new one, old symlinks are replaced by new and we have make sure that this won't create problems. > As to bloatedness, there's an apt-hook installed on the device that > removes the extra docs when a package is installed (at least man & info > pages). good to know. although sometimes I find the absence of docs an obstacle (would be nice if they could be saved to one of the mmcs) > Developer could also run something like Debian's localepurge. > Most of the package sizes can come from documentation and localization > (which Busybox tools are lacking), sometimes also from extra binaries. > IMHO the actual binary size is significant only in fairly rare cases. >N8x0 devices have more Flash available than 770, so the disk usage >isn't anymore as severe issue as it was. This differs from package to >package, so the decision about this needs to be done case by case. I'll think about this. If it is really true that binary size doesn't matter, then that's a strong case for not using busybox at all (or at least offering a full versioned drop in toolset replacement for busybox) >However, I don't think it's a good idea to add more tools to Busybox. >Busybox is an essential package, so having incompatible versions of it >or trying to replace some of the binaries with the real versions will >end up with packaging conflicts. that's why I advocated making it optional. to resolve the conflict, reinstall the slimmed down one. Can busybox be configured to use shared libraries for classes of toolsets? that way, optional packages could be provide distinct functionality in a shared object with accompanying symlinks without the need to overwrite the busybox binary. > >IMHO only good reasons for adding a tool to Busybox would be >compatibility to Debian (derived distributions) from which most of >the other maemo tools come from. I.e. if Busybox claims to provide >a certain Debian package, it should try to provide as many binaries >from that package as possible. And even this only if: >- The real package (without docs and localization) is significantly > larger than the corresponding Busybox binaries size >- The package in question is an essential in Debian and at least some > of its binaries are used by the preinstalled device software .... >It would be nice to have a bug about that with details about what >Busybox options should/could be enabled/disabled and what will be >their effect to Busybox size & RAM usage. What are your propositions >for enhancing the currently configured Busybox tools? ok, at the very least I think all of the coreutils should be available with more options switched on (personal favorites: diff, patch, color coded ls etc). I'd also like to have all of the archive tools available but maybe I'm in the minority. Even a busybox with virtually everything switched on is only 740kb binary. I can't imagine RAM usage would be an issue. I'll add more later, when I file the bug >What's the problem of using the real packages / functionality instead >(specific example, please)? E.g. if you want a good interactive shell, >why not add that as a separate package (Busybox POSIX shell would >then be used only by the shell scripts)? the problem isn't a specific one, it's a general one. 1. it requires a package hunt to create a working system (perhaps this is resolved by the creation of a super package that installs all of the others). 2. I can't help but think there will inevitably be small patches to the debian packages that makes maintenance of many sets of packages a nightmare. Maybe I'm wrong about that.
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
