On Saturday, September 18, 2010 06:28:42 am David Greaves wrote: > My compliance wording proposal is: > > Applications *MUST NOT* require (in RPM terminology) packages that are not > themselves compliant. > > Applications that require (in RPM terminology) packages that cannot be > provided > MUST NOT be installed. > > Please comment.
First, this is a NO-OP. It basically says "applications must depend on a package set that ultimately is only depending on MeeGo." Of course! Otherwise it won't run. Let's *NOT* try to make repsoitory-driven app sets "MeeGo Compliant." The whole point of "MeeGo Compliant" is to be able to install a single App and be sure it works. Meanwhile, repository-driven apps should /not/ be installed in /opt. Instead, why not leave "MeeGo Compliant Apps" alone and carve room in the spec for "MeeGo Extras." Either allow only one "Extras" repos. Or PREFIX all the repositories to /usr/extras/org.some/ (hacking the path and ld.so to search there). Meanwhile, it's pretty clear what we want from MeeGo Core, MeeGo ODM Implementations, and MeeGo Compliant Apps.... so let's get those finalized quickly. :-) > I would anticipate that installation from an app store could streamline this > process through negotiation: > "this app needs X=<ver>,Y,Z"... "OK, can meet"..."here's the app" But app Q=<ver>,T,F But app T installs a file /usr/share/icons/kewl.png And app Y also installs a file /usr/share/icons/kewl.png Since T and Y conflict (rpm won't let you install both unless you're a ninja), so does Q and X. Very uncool, especially since they are all "compliant" according to your definition. RPM can't manage that... packages T and Y have to be coordinated by people. -gabriel _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
