On Tue, Sep 07, 2010 at 04:19:19PM -0600, Wichmann, Mats D wrote: > Someone else said there are simply two different models: > the repository-based model where the installer resolves > certain dependencies (and it's easy enough to SAY something like > "may only depend on components of MeeGo core, or from MeeGo > compliant packages"); and one where an app may have no dependencies > at all, basically "depend on MeeGo" is it, everything else is > self contained. Should this even be part of the compliance discussion? Sorry if this sounds harsh, but if some vendor's app store can't support dependencies properly surely that's the vendor's problem to solve (and they would have to since developers are likely to vote with their feet and use better distribution channels). In any case, app stores are free to impose any additional packaging restrictions they please in their terms.
Or perhaps we should turn this around and start discussing the criteria for MeeGo-compliant repositories? > It seems like the wind is blowing in the direction of the latter, MeeGo core can't (and shouldn't) include everything and the kitchen sink, and there's bound to be useful stuff not present in core that developers will want to use. If every package is forced to be self-contained we will end up with the same dependencies (libraries, interpreters and so on) bundled over and over again in different packages. The overhead (download sizes, RAM and filesystem footprint) of bundling everything in each package is just silly, especially for the type of device MeeGo targets. Maintenance is also going to be a major headache as each application packager is going to be individually responsible for every dependency they ship, and the user won't be able to tell whether for example a security vulnerability in libfoo has been patched across their entire system. There are also some types of dependencies (eg daemons or dbus services) for which it may be very difficult or even impossible to have multiple concurrent instances. Of course any packager who wants to build all-in-one bundles is free to do so, but please don't force this on everyone by institutionalising it in the compliance spec. > It went in the spec that way based on what people who worked > on this were told; hoping the discussion will make it clear what > the spec actually needs to forbid/allow in this area. Note that the draft does indicate that non-core dependencies are OK in at least a couple of places: - 157-158: "Application packages SHALL “require” (in RPM terminology) all system and third party components that are necessary for them to run." - 227-232: "All MeeGo compliant application executables [...] shall import external interfaces from one of the following sources: [...] shared libraries from third party packages that are MeeGo compliant itself and are listed in the RPM package dependencies; So I *think* the intent must have been to allow this, at least at some point. L. _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
