On Sat, Sep 18, 2010 at 6:20 PM, Carsten Munk <[email protected]> wrote: > 2010/9/18 Andrew Flegg <[email protected]>: >> 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? > > No, I'm saying that if there's any dependencies of the application > that would be resolved through the installation source, these > dependencies can only be from the set of binary packages being built > as part of the applications' source package.
It concerns me too at installation time, fooapp from AppUp should have the following simple logical installation tree available: Everything in AppUp Everything in Profile Everything in Core Dependency resolution should be simple to organise in that situation. If each library must be embedded inside applications it will cause MORE security problems than it solves. With X different packaged up libbaz versions from different applications using it, how would they be patched in a timely manner? > > The challenge is that if we dilute this, we risk that people dump in, > let's say, SDL and it would conflict with another repository also > hosting SDL. We won't see people putting same application in multiple > places, I would hope.. You will have massive problems with this limitation, its nothing to do with diluting it. SDL is a dependency for many large OSS applications. Using the SDL example, if it is available in core and also Intel AppUp (for use by other AppUp applications) then the latest will be used? Just like it does now Or did dependency resolution go out of the window with the change to RPM? BR Gary > > Best regards, > Carsten Munk > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
