Speaking of the init system being upstart (*sigh*... just saw this thread's tags... At the time of this writing four out of five of them are largely-irrelevant-to-productive-discussion troll/spam tags mentioning Estel by name.)

Anyway, speaking of the init system... I must say I like upstart more than for example systemd or the old-school SysV init, and of the really common and popular init systems, I'm glad our N900 uses it. I'm also really glad to hear that CSSU-devel has an update for it coming.

That said, I think it would be nice if in the long run, the dependency that the CSSU package required became not necessarily Upstart, but some sort of list of virtual packages standing for the required features. Like how we do with the various kernel-power derivatives.

An updated Upstart could then put those in the 'provides' field of it's deb packaging - and so could any other set of packages that provides the agreed-upon underlying functionality that we actually /need/.

I hope that if someone ever put together an init/event system for our aging N900s that I thought was better for my device(s), that the CSSU metapackage dependencies will not require me to fight against the packaging system to switch, like I think I would have to right now.

Now, I realize how extremely deeply an init system like Upstart is coupled to the whole system, so I would even be fine if this virtual package was unapologetically upstart-focused (e.g. the virtual package could be called "upstart-[version-number]-compatible", or something like that). Simply requiring the alternative to do a 'Provides: upstart" would be fine by me too, though the provides field supports only package names, not version numbers, so if the upstart dependency of the CSSU metapackage is as rigid by version as some of the other dependencies have been in my memory, then such a 'Provides' field wouldn't enable such a swap as things are.

Actually in context of the very last post about how it's in some system-services package, I get the impression that things are even more tightly coupled (I imagine this package bundles several low-level system things together). It would be nice, I think, if the long term goal was to split those up and package them more independently, again allowing for alternatives to be provided and for the CSSU to depend on one or the other based on virtual/meta packages, instead of on specifically one.