Comment 5 for bug 487456

First a disclaimer: even if below may sound like complaining, I do very much appreciate the work of core Ubuntu and Debian developers (as well as the whole community and upstream software developers), and I don't think they have any "obligation" to do things they don't think important or the right thing.

Colin: I actually now read the related part of Debian policy manual, which I of course should have done as the first thing. To nitpick, it's not that a package *must not* depend on an essential package, it just *should not* depend on it unless package requires a specific version number of an essential package, so it's not strictly forbidden. But according to the policy, the bug is invalid, thanks for closing it.

Related, if anybody feels passionate about following Debian Policy Manual, feel free to submit a bug against lsb-base (at least version 4.0-0ubuntu5). It depends on sed and ncurses-bin, both essential, without specifying version numbers, and this should "generally be considered a bug" as far as I can see ;-).

Related rant: essential depending on optional, or just dependencies going against priorities sounds quite wrong to me. The simplest solution could be having virtual packages to depend on, and then these could be provided by packages with lower priority than the package depending on the virtual package. Ideal solution would be to re-factor functionality or change package priorities so that "wrong way" dependencies disappear. Oh well, I guess this is a total non-issue in most cases.

About embedded installation of Ubuntu or another desktop distro: There are different kinds of embedded applications, and for some of them, being able to have a non-broken OS can be just about as big an advantage as having a non-broken OS for a LAMP server. Actually the embedded PC could end up being a LAMP server, among other things... In applications like this, ripping stuff out is just about as desirable as ripping essential stuff out of a "real" server installation. Emdebian Grip is a step in this direction, but it was unsuitable (read: much more work in the long run) in this case.

Also having custom versions of core packages like bash would be a pain when upgrading to 10.04 LTS soon, and would partially defeat the purpose of using an LTS version maintained by "somebody else".

Anyway, in this case the solution was to have normal Ubuntu installation, but move some stuff (like the maintainer scripts, docs etc) to a non-internal storage, which needs to be mounted only when OS maintenance is required. Seems to be quite an elegant and flexible solution so far, allowing "unlimited" space for maintenance and development stuff, while leaving plenty of room in the internal storage for future needs.