On Sat, Sep 18, 2010 at 18:35, Carsten Munk <[email protected]> wrote: > [snip]
Firstly, thanks Carsten for trying to come up with a clean-sheet proposal. Much of the logic (regarding lock-downs and single RPMs delivered over HTTP) seems eminently sensible and self-consistent. > #2 A MeeGo application may only depend on packages within: > > MeeGo Core repository (for the particular version of compliance it is > targetted on) [this doesn't have to be repo.meego.com, can be a vendor > mirror] > and the MeeGo Profile repository it may be built for (or the > particular version of compliance it is targetted on). Profile means > Handset, Netbook, Tablet, etc. [same as above] > > And it's installation source. This avoids the dependency graph of repositories problem, but is a sensible half-way house. > #3 With dependencies that originate within the installation source, > these packages may only be packages that originate from the > application's own source package. > > Reasoning: We should encourage same packaging practices as we have in > MeeGo. This means packagename-devel, packagename-doc, etc. (bad > examples for a package depending on other parts of itself) This bit concerns me, so either I'm not understanding it or we've found a bone of contention. Are you saying that: fooapp which depends on libbaz (both of which are in, say, MeeGo Surrounds) and libbar (in MeeGo Core) can *only* be compliant if foo.tar.gz built fooapp.rpm and libbaz.rpm? And that barapp could not be compliant if _it_ depended on libbaz? Thanks in advance, Andrew -- Andrew Flegg -- mailto:[email protected] | http://www.bleb.org/ Maemo Community Council chair _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
