Hi Tom, You may find some answers to your fundamental question here (slide 13 in particular): http://fr.slideshare.net/rzrfreefr/tdc2014-tizen-common20140603-35687894
The (maybe too implicit yet) rules for Common packages are: - if a package is considered as a base package and should be present in *all* profiles, then it's present in Common and profiles will align on the one in Common => a "Core Common Packages" *MUST* be used inside any profile - if a package is used in *some* profiles (at least 2 profiles OR if only 1 profile but package is expected to be reused in other profiles later), it may migrate to Common in the "Shared Common Packages": QT5, Ofono etc. fall in this category => a "Shared Common Package" *MAY* be used in a given profile - if a package is used in only 1 profile and is considered as specific, it's not supposed to land into Common => a "Profile Specific Package" *MUST NOT* be in T:Common For your second question, the process to migrate to Common is not difficult: usually a profile specific package exist in profile/<xxxxx>/<package>. The process is roughly: - relocate the git to global place (ex: platform/upstream, platform/adaptation, ...) ouside profile/ subdir - submit to common (gbs submit) - resolve the conflicts - accept the new package in Common On next sync, a profile aligned on Common will have to relocate the package inside the OBS project. NB: if there's no basename change on the git, this can be handled automatically by new submissions (ex: profile/ivi/dLeyna will migrate to platform/upstream/dLeyna and the package name doesn't change: it's still 'dLeyna': the new submissions coming from the new git will override the package sources in OBS). Hope this clarifies a bit. Best regards, Stéphane -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 On 10/07/2014 13:37, Counihan, Tom wrote: > The thread triggers in my head a question - what is the boundary of common? > My investigation leads me here: > https://wiki.tizen.org/wiki/Common > "Strictly speaking, Tizen:Common is not a "vertical" profile. It's the common > base for other profiles (IVI, Mobile and other forthcoming profiles)." > > Then here more detail: https://wiki.tizen.org/wiki/Common_Packages > Where I see "Common/Wayland" but no Common/X11. > > I appreciate it's a challenging task to adjudicate. But my mind wanders to > upcoming IOT, and wonder for example if such a device has no audio/display > behaviour, is Pulse so common, or even wayland/x11/xwalk itself? > > My fundamental question I guess is, what is the criteria for elevating > something into common or relegating it to profile specific? > Secondly, what is the change control process for managing this transition > into or out of any components current allocation? > > Apologies if this is documented somewhere, I just haven't found it. > > Warm Regards > Tom. > >> -----Original Message----- >> From: Dev [mailto:[email protected]] On Behalf Of Dominig Ar Foll >> Sent: Thursday, July 10, 2014 11:39 AM >> To: [email protected] >> Subject: Re: [Dev] [Common] ARM Images, X11 repos and respect of the >> workflow >> >> Hi, >> >> I can only strongly agree with Stephane, non respect of the process creates >> non >> cnstructive mess which are penalising all of us. >> In the case of Common it's even worse, as it affects each derived Profiles >> and >> architectures. >> >> We have been looking for the days on the best model to add X11 to Common >> without letting X and Wayland package request mix up silently like it used >> to be >> in the past. >> >> It took a long time to clear those silent package mixing issues and we do not >> want them back. Loading undesired and unused lib in an embedded OS is not >> good and shall be avoided. >> >> The X enabling investigated model (in a private OBS to avoid to break any hot >> projects relying on a working Common) is based on the use of a project Conf >> which will create invalid calls to packages if a request to an X11 >> dependency is >> done in a Wayland repo and vice versa for X. >> >> We will propose our model in a few days in this list, as soon as we will have >> checked that it can work, and will call for feed back before implementing in >> agreement with all involved parties. >> >> In the mean time, we need to go back to the previous model where Common >> was building clean which is a pure loss of time. >> >> Regards >> >> >> -- >> Dominig ar Foll >> Senior Software Architect >> Intel Open Source Technology Centre >> _______________________________________________ >> Dev mailing list >> [email protected] >> https://lists.tizen.org/listinfo/dev > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
