ext Dave Neary <[email protected]> writes: > Since many packages include shell scripts for pre- or post-inst > operations, or even for run-time set-up, it seems reasonable to define > some kind of subset of commands and some version of a standard shell. > Without going overboard, of course.
Yes, and the spec generally does (will do) this by listing concrete packages in Appendix A, if I understand things right. For example, it will likely list "coreutils" in Appendix A, and then you look at the MeeGO release that you are targetting and that tells you which version of coreutils will be in any MeeGo product that claims compatibility with that MeeGo release. This isn't very pure, since it allows people to get away with coreutils specific code which reduces the portability of their code to other platforms than MeeGo, but that's their problem, not ours, as long as our coreutils are reasonably POSIXY and we don't force them to be coreutils specific. It also means that we are tied to coreutils for at least one major version of MeeGo, of course, but that's fine IMO. And to conclude the argument: If we do this for coreutils, we can just as well do it for bash. I don't see a reason to single out the shell, or for that matter, other language run-times. > Similarly for scripting languages, if you're writing a Python app it's > important to know that Python 2.7.x won't be on any MeeGo device. Do you mean "won't be on _all_ MeeGo devices"? It should be totally feasible in general to package extra dependencies of your applications for MeeGo. Packaging Python 2.7 might be a bit excessive just for a tea timer, but there shouldn't be anything that prevents it in principle. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
