Re: [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

[Denys Dmytriyenko <denys@ti.com>]

On Fri, Jun 28, 2013 at 07:25:04AM -0400, Maupin, Chase wrote:
> 
> >> Well, if every time you update SRCREV you also increment the
> >first letter, it
> >> will work as expected - so the comment is kind of correct... :)
> >>
> >
> >Right, I just followed the existing kernel recipes for convention.
> >Would
> >the convention change between a kernel recipe (like
> >recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both
> >SRCPV
> >and the first letter, compared to userspace recipes which point to
> >git
> >trees for versions?
> 
> The kernel ones were to append the MACHINE_KERNEL_PR that was set with the 
> letter.  The SRCPV use was also nice to make it easier to know which 
> commitid was being used during the kernel build.
> 
> >>> That being said if you were going to overlay this recipe the PR
> >should be
> >>> something like
> >>>
> >>> PR = "${INC_PR}.0"
> >>>
> >>> Right now you are appending to the default since PR is not
> >defined.  With a
> >>> bbappend you should append a -arago flag.
> >>>
> >>> So this comes back to why no bbappend?  Is it because the base
> >version in
> >>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git
> >version of
> >>> the recipe and update the PV appropriately?
> >>>
> >
> >That's also possible but the question I have is what's the
> >preferred
> >convention?
> >
> >All the GLSDK trees are on git. The choice really is between
> >having a
> >since .bbappend for each of the trees with an explicit PV and bump
> >the
> >PV everytime we update to latest on upstream *OR* have a recipe
> >for the
> >version and submit a new recipe when we update to latest.
> >
> >I can submit a v2 once I understand the expected convention to be
> >followed.
> 
> I get your point on clarity so I'm OK with a version specific addition.  You 
> may have answered this before but what is the difference between your libdrm 
> and the libdrm upstream?  Are your patches going upstream to the main libdrm 
> so that going forward you can drop this recipe for a new version?
> 
> Denys, refresh my memory if we are doing a version but we are also changing 
> things in our trees don't we normally do this as something like ti-libdrm 
> and set the PROVIDES, etc for libdrm?  This was to distinguish between 
> libdrv 2.4.41 for example and what TI is calling 2.4.41 right?  Or do you 
> just want to do 2.4.41+?  What is your preferrence?

From my past discussions with Nicolas, TI's libdrm is quite close to the 
upstream and the patches are meant to be upstreamed eventually. So, 
technically it's not a complete fork and having a full replacement like 
ti-libdrm is not really necessary here. I'm fine with providing own 
libdrm-2.4.41 recipe for now.

-- 
Denys