Hi Mark, Skarpness, Mark wrote: > It actually does matter to those deploying devices. A few examples of why: > > If compliant apps are allowed to have external dependencies - then > someone has to pay to host and maintain those dependencies so they are > available worldwide to many millions of devices.
Won't that be the MeeGo repository? > As someone building a device - how do I know how much storage is required for > the OS in order to run compliant apps (as Arjan pointed out earlier in the > thread)? This reminds me of an epiphany I had a few years ago when working with a buy who was an embedded developer. He told me stories about doing real-time development & having to turn off all caching for the OS and applications for an embedded application that was going into space - it didn't matter that the average response time was going to be increased from 0.01s to 0.5s, what mattered was that he could give, with absolute certainty, a *maximum* response time. Being better in theory was less important than being predictable & reproducible. In theory, depending on external apps will raise the average space used when installing 100 apps, but it does not give any decent way to evaluate the maximum space that will be needed for 100 apps. However, including all dependencies in packages will always give a higher space requirement for the 100 apps than splitting them out... either all dependencies are used by exactly one package (in which case the result of including them or splitting them is the same) or at least one dependency is shared by at least two packages (in which case splitting them out is better). There is no situation where having separately-packaged dependencies will use more space than dependencies wrapped in the package. It occurs to me that going in this direction would be like returning to the early days of Linux when there were no dominant distributions or common base packages or decent dependency resolution, and WordPerfect, Applix, Oracle and all the other commercial apps that started supporting Linux used to ship huge statically linked packages. Can we all agree that the world was a worse place for Linux users back then? <snip> > Absolutely - but MeeGo also needs to meet the needs of people > building commercial device products and applications - so the rules for > how you build and distribute that GPL application may be a bit different > then they would be for a "standard" Linux distro. I guess I can assume that most people here have not been in the business of building commercial device products and applications - it seems like there are not a lot of people from that segment here to defend their own needs. Perhaps it would be useful to go over the core requirements that these constituencies have? I can get that a commercial application developer wants to be able to build a package which will install on any MeeGo device... we're not talking about requiring that people split off dependencies, but allowing that things can be done like that. I can get that an app store might require these single packages for billing purposes, as you said. And I think that would be fine for anyone wanting to get into an app store. I'm still not very clear on what requirements a device vendor/distributor (or software strack provider) might want to impose on the software that would be installed on the device. Are there distributors who want to have a single approved source of applications for their devices that they support? And they don't want to be required to enable some wild hairy community repository? Or am I missing the point? A clear list of the constraints & requirements of commercial developers & distributors would be, I think, useful. Thanks! Dave. -- maemo.org docsmaster Email: [email protected] Jabber: [email protected] _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
