[meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15
Denys Dmytriyenko
denys at ti.com
Sun Jun 30 21:51:46 PDT 2013
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
More information about the meta-ti
mailing list