[yocto] [meta-selinux] git recipes

[Mark Hatle]

On 2/27/16 10:23 PM, Philip Tricca wrote:
> Adding a sensible subject.

Sorry couldn't reply when I saw this when you first sent it.  Corporate email
server went down for those of us who DON'T use outlook.. argh..

Anyway..

What I'm generally used to in the Yocto Project work is that the 'git' version
picks a specific git snapshot and makes it a quick operation for someone to
arbitrarily change that snapshot by adjusting the SRCREV.

We don't use the AUTOREV parameter, because that causes the system to have to do
a git pull in order to evaluate the available versions and determine the SRCREV
to use.  So it's all down to a parsing and performance issue.

What I've done on some of my own projects is have an AUTOREV version (locally),
then when it triggers a recipe breakage, I think update the SRCREV and fix it in
the remote tree..  so I get the autorev, the world gets a version of the package
that keeps working.  (I also update the SRCREV other times as well.. but the
autorev breakage is one of the key triggers.)

Joe might have some suggestions as well, I'm not against AUTOREV per say, but I
am worried about any performance issues during the parse.

--Mark

> On 02/27/2016 08:17 PM, Philip Tricca wrote:
>> While going through the backlog I ran across the 'git' versions of the
>> user space. I noticed that a recent contribution was adding a patch to
>> the git recipe and I figured that this patch would already be upstream
>> and so wouldn't be necessary. Not so. The 'git' versions have SRCREV
>> hard wired (SRCREV) to a commit id but it's way back from the end of
>> 2013. They're also disabled via DEFAULT_PREFERENCE = "-1"
>>
>> These 'git' versions seem super useful for testing bleeding edge stuff
>> so IMHO keeping them around would be the right thing to do. Not sure how
>> I feel about them tracking an ancient commit though. Since they're never
>> built by default it seems reasonable to track the master branch.
>>
>> What's our philosophy w/r to recipes that pull from git? Is there some
>> history behind this SRCREV?
>>
>> Thanks,
>> Philip
>>
>