On Sat, Sep 18, 2010 at 08:20:09PM +0200, Carsten Munk 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.
>
> 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..
Assume I'm providing 5 applications using SDL, each in an own
repository.
Then I'll dump the upstream SDL souces into each of the 5 source
packages, and each of them will build a libsdl package that will
then be available in the repository of this application.
If there's a security bug in SDL, I have to manually update the SDL
sources in each application.
Is that a correct understanding of your proposal?
Also note that it is possible that for legal and/or political reasons
the library cannot be included in MeeGo Core or MeeGo Profile
repositories (consider e.g. audio/video codecs and software patents).
> Best regards,
> Carsten Munk
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
