[MeeGo-dev] [compliance] Different view on app compliance
liquid at gmail.com
Sat Sep 18 12:38:51 PDT 2010
On Sat, Sep 18, 2010 at 6:20 PM, Carsten Munk <carsten at maemo.org> wrote:
> 2010/9/18 Andrew Flegg <andrew at bleb.org>:
>> On Sat, Sep 18, 2010 at 18:35, Carsten Munk <carsten at maemo.org> wrote:
>> 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
>>> 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?
> Best regards,
> Carsten Munk
> MeeGo-dev mailing list
> MeeGo-dev at meego.com
More information about the MeeGo-dev