[yocto] [meta-selinux] git recipes

[Philip Tricca]

On 03/02/2016 07:47 AM, Radzykewycz, T (Radzy) wrote:
> ________________________________________
> On 3/1/16 21:40, Philip Tricca wrote:
>> On 03/01/2016 10:30 AM, Joe MacDonald wrote:
>>> [Re: [yocto] [meta-selinux] git recipes] On 16.02.29 (Mon 08:06) Mark Hatle wrote:
>>>
>>>> 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.
>>>
>>> This has been the approach I'd always tried to take with _git recipes as
>>> well and it tends to work very well for ones that are either the only or
>>> the preferred recipe.  I think in our case we were always preferring the
>>> released versions for several historical reasons and the _git recipes were
>>> relegated to the second-tier because of it.  But that means that basically
>>> they never got updated.
>>>
>>> About a year and a half ago I started seriously talking about dumping the
>>> userspace tools entirely and only ever working out of the _git recipes.
>>> Shrikant started doing that work after I discussed it with him but we
>>> never got beyond the policy recipes.  So if you guys think this is not a
>>> completely insane thing to do, that's the direction I'd like to go with
>>> this.
>>>
>>>> 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.
>>>
>>> And avoiding surprises on the other side of the bathtub curve, when
>>> updates pop up that we aren't prepared for.  :-)  But we've been behind
>>> on developments aging out, too, so I don't have a strong case to argue
>>> against AUTOREV.
>>>
>>>> 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.
>>>
>>> I would really rather avoid AUTOREV, but I think the way we would
>>> accomplish that is to edge away from our current recipes and bring the
>>> _git ones back to centre stage.  Then we're likely to stay on top of a
>>> fixed SRCREV anyway.
>>
>> I think there's something to be said for a simple approach. For those
>> showing up and trying to figure out what's going on / how the build
>> works it would likely ease their entry if we had straight forward
>> recipes that build from the usptream release tarballs. For those wanting
>> to verify hashes published by upstream (and maybe signed) this makes
>> life easier as well.
> 
> My comments, FWIW:
> 
> I'm not sure I agree that having both recipes is a simple approach.
> 
> If you're getting started, then you may not be aware of how
> PREFERRED_VERSION works, or even that it is available at all.
> Depending on your personal inclination, you may assume one way
> or the other.
> 
> Using a _git recipe as default, where SRCREV points to something
> similar to the latest release might be a better way than having
> two recipes.

Fair points.

>> Mark's point is well taken though and there's lots of value in having
>> the git recipes for those who want to experiment. I think Marks test /
>> development setup / tracking AUTOREV behind closed doors is very useful.
>>
>> In the interest of not making too many changes too early on I'd like to
>> propose the following:
>> - keep the release-tracking recipes the default, no change in
>> PREFERRED_VERSIONs etc.
>> - Keep the git recipes around and still pointing to a static SRCREV
>> - Update SRCREV to the latest release and keep it up to date as we move
>> the userspace etc forward
>> - Do not maintain a patch queue for the git recipes
>>
>> I think this last point is likely the only departure from our current
>> approach (and my 3rd point is just an update). My reason for removing
>> the patch queue is that if someone wants to experiment with git they'll
>> likely not want any of those patches. The patch queue will probably just
>> get in their way.
> 
> I like the idea of not maintaining a patch queue for git recipes.
> I'm not sure how well it will work in practice, though.  This
> policy would assume that all git recipes are for projects that
> are maintained by reasonable maintainers who accept our input.
> Maybe that's the case most of the time, but I doubt it's always
> the case.  A trivial change to "Do not normally maintain...." would
> sit with me better.

Agree. What I want to avoid is the current situation where people are
submitting patches that add backport patches to the _git recipes that
are already in the upstream git repo. Carrying around patches that
aren't upstream yet (or as you point out, necessary but not accepted
upstream) may be necessary.

Thanks,
Philip

> Enjoy!
> 
> 				-- radzy
> 
>>> But as I say, maybe I'm completely insane on this point.
>>
>> Nothing insane but I'm feeling conservative, maybe just till the dust
>> settles. Agree / disagree with the above as a first step at least?
>>
>> Philip
>>
>>>
>>> -J.
>>>
>>>>
>>>> --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