[yocto] [meta-selinux] git recipes

[Joe MacDonald]

[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.

But as I say, maybe I'm completely insane on this point.

-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
> >>
> > 
> 
-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160301/7829ee0f/attachment.pgp>