[yocto] [PATCH 0/2] Add some recipes

Tue Dec 2 12:48:29 PST 2014

Guys, lets keep Bian in the loop. though, so he does not loos the thread information.So to conclude: 
1.) one of us(or anyone in the community) should find the time to investigate if only one multipath tools recipe is applicable and if that is the case keep one in the meta-oe, eventually update it.Since it it related to meta-cgl could take a step forward on this because there could be some bbappends applicable for meta-cgl there, but it will take 2/3 weeks until I will be able to do this. So anyone else interested is welcomed to do it if they are in a hurry.2.) We kind of torn apart Bian`s patches and maybe he will not be so willing to do redo the patch for drdb, Joe will you be able to do the required changes for making sure his patch can be integrated inside meta-networking.
Thank you for your time and patience.

Alex Vaduva

     On Tuesday, December 2, 2014 10:33 PM, Bruce Ashfield <bruce.ashfield at windriver.com> wrote:

 On 14-12-02 03:17 PM, Joe MacDonald wrote:
> [Re: [yocto] [PATCH 0/2] Add some recipes] On 14.12.02 (Tue 14:49) Bruce Ashfield wrote:
>
>> On 14-12-02 02:37 PM, Joe MacDonald wrote:
>>> [Re: [yocto] [PATCH 0/2] Add some recipes] On 14.12.02 (Tue 14:03) Alexandru Vaduva wrote:
>>>
>>>> Hello Bian,
>>>>
>>>> Did you know that the multipath tools recipe was also available inside the
>>>> meta-oe and meta-virtualization?
>>>> I do not have any problems with it being available in meta-cgl.  I just wanted
>>>> to hear other opinions because I would like to make sure we do not get to that
>>>> point where we keep various versions of various recipes in a variety of places.
>>>> It will be a nightmare to work with them in the future.
>>>
>>> I completely agree, and I that's mostly the consensus of the community.
>>> Since meta-cgl already has dependencies on both meta-virtualization and
>>> meta-oe, I think it makes the most sense to try to keep updates for the
>>> multipath recipes in one or both of those layers.  My recommendation
>>> would be to update the meta-oe one as it has broader applicability, but
>>> of course that's up to the submitter and the layer maintainers to
>>> decide.  It may be that it's appropriate to maintain a bbappend for the
>>> recipe in meta-cgl, but I think it'd be good to send it for inclusion in
>>> meta-oe first.
>>
>> I'm with Joe on this one.
>>
>> I only did a really quick check on the history of the two copies
>> that we have, but I see the meta-virt variant was added in January 2013
>> and what could be the first version in meta-oe in March the same year.
>
> I actually intended to say "update the meta-oe one as it has broader
> applicability and if you're feeling ambitious, send the same update to
> meta-virtualization" since I thought meta-virt didn't have dependencies
> on meta-oe and I can see an argument in favour of keeping a separate
> recipe if you're keeping the layer contained.  But it looks like that's
> not the case, so consolidation makes sense here.

Yep, there are dependencies on meta-oe where it makes sense, or if
there's a package in meta-virt that isn't particularly twitchy about
versions and update cadence.

>
>> The layer index may not have been as helpful back then (but honestly
>> I can't recall) .. either way we failed to coordinate as a wider community
>> and managed to end up with two different recipes in the layers.
>>
>> There's no sense making this any worse than it already is, so I'd say
>> that we could spend the time looking at the two (three?) recipes, and
>> get a consolidated variant in meta-oe, and I'd be happy to drop the
>> one in meta-virtualization and bbappend the same way that Joe suggests.
>>
>> Thoughts ? We should figure out if someone is going to take a crack
>> at it, so we don't all go do the same thing :)
>
> It's not on my to-do list, so don't worry about me running in parallel.
> iscsi was (and is again) the only meta-networking one and libcap-ng (as
> discussed with Armin the other day) and swig are the meta-selinux ones.
>

Sounds good.

Bruce

> -J.
>
>>
>> Bruce
>>
>>
>>
>>>
>>> Just my thoughts on it.
>>> -J.
>>>
>>>> Once again, just to make it clear. I am ok with the patches, I will merge all
>>>> three of them (corosync, multipath and drbd) but I just wanted to make sure you
>>>> took this into consideration.
>>>> Also I like the idea of having drbd recipe inside and the fact that you like to
>>>> get involved in this initiative.
>>>> Hope to hear more from you and also that I will be able to help more.
>>>>
>>>>
>>>> Alex Vaduva
>>>>
>>>>
>>>> On Tuesday, December 2, 2014 10:07 AM, Bian Naimeng <biannm at cn.fujitsu.com>
>>>> wrote:
>>>>
>>>>
>>>> Bian Naimeng (2):
>>>>    [meta-cgl] device-mapper-multipath: add recipe
>>>>    [meta-cgl]drbd: add recipe
>>>>
>>>> .../device-mapper-multipath/multipathd.init.patch  | 12 +++++
>>>> .../device-mapper-multipath_0.5.0.bb              | 53 ++++++++++++++++++++
>>>> meta-cgl-common/recipes-cgl/drbd/drbd/drbd.service | 12 +++++
>>>> meta-cgl-common/recipes-cgl/drbd/drbd_8.4.4.bb    | 57 ++++++++++++++++++++++
>>>> 4 files changed, 134 insertions(+)
>>>> create mode 100644 meta-cgl-common/recipes-cgl/device-mapper-multipath/
>>>> device-mapper-multipath/multipathd.init.patch
>>>> create mode 100644 meta-cgl-common/recipes-cgl/device-mapper-multipath/
>>>> device-mapper-multipath_0.5.0.bb
>>>> create mode 100644 meta-cgl-common/recipes-cgl/drbd/drbd/drbd.service
>>>> create mode 100644 meta-cgl-common/recipes-cgl/drbd/drbd_8.4.4.bb
>>>>
>>>> --
>>>> 1.9.1
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20141202/075b874b/attachment.html>