[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
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto