On Thursday 27 February 2014 18:18:29 Paul Eggleton wrote: > On Thursday 27 February 2014 17:32:29 Alex J Lennon wrote: > > On 27/02/2014 17:09, Paul Eggleton wrote: > > > On Thursday 27 February 2014 08:30:10 Khem Raj wrote: > > >> On Feb 27, 2014, at 7:59 AM, Alex J Lennon > > >> <ajlen...@dynamicdevices.co.uk> > > >> > > >> wrote: > > >>> On 27/02/2014 15:50, Khem Raj wrote: > > >>> > On Feb 27, 2014, at 6:16 AM, Alex J Lennon > > >>> > > >>> <ajlen...@dynamicdevices.co.uk> wrote: > > >>> >> +PR = "r1" > > >>> >> > > >>> >> + > > >>> > > > >>> > get rid of that > > >>> > > >>> Why is that Khem? > > >> > > >> we have automatic PR server now a days, its enabled by default. > > > > > > FWIW, I don't think it's enabled by default, at least not in > > > OE-Core/Poky. > > > The point still stands though, it's the way PR should be managed rather > > > than manual bumping. > > > > <googling/> Are we talking about the "network based PR service"? > > Yes, see: > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working > -with-a-pr-service > > Is this a single globally available nework service or a service that's > > intended to be running local to a specific build farm? > > Specific build farm; it may be made externally accessible if necessary > however. > > > My reading of the wiki page seems to imply it's intended to be local to > > a build farm, or system, rather than globally unique? > > PR values needn't match up between different distros. The point is they > should get increased when a material change to the recipe's output happens; > and this can happen for example when: > > * A class that the recipe inherits is changed > > * A dependency of the recipe that influences how the recipe is built gets > changed > > * Some global configuration changed that affects how the recipe is built > e.g. DISTRO_FEATURES > > * A bbappend is added or removed > > In all of these cases the recipe itself does not get changed at all - prior > to the PR server we had to remember to manually bump PR in the affected > recipes, or (more often) we'd forget to handle it properly altogether. With > the PR server, PR bumps happen automatically in response to signatures > changing, which is about as accurate an indicator as we can get as far as > determining whether the output has changed, and certainly much less prone > to mistakes. > > So if I'm releasing packages to production this now becomes a critical > > part of my infrastructure as I'll lose all my package revisions if > > something goes wrong with it? > > Yes. Luckily it's not a particularly complicated piece of software; the only > extra thing you need to preserve is the sqlite database that contains the > hashes and corresponding PR values. > > > And my packages will have different revisions from somebody elses's > > packages when they are running their own network based PR service? > > Yes. If bbappends were involved all bets were off prior to the PR service > anyway since they were supposed to modify PR. > > > I suppose the other question is, if I release a package of revision X, > > then another which is up-rev'd' to Y as I made a change to the recipe > > and so the NBPRS up-revs, then somebody comes back to me and tells me > > they are having a problem with Xm then how do I link that rev X to the > > specific commit that went to build it so I can audit ? > > The PR server doesn't track this - however, all of this information does go > into buildhistory if you enable that. > > > I haven't enabled this here, so does that mean all my package revisions > > will be r0 as I remove the PR variables from recipes ? > > We're not talking about dropping all PR values in existing recipes, we're > talking about dropping them on upgrade (i.e. when PV changes), where > previously we'd have done that anyway or set them to "r0".
I should point out also in case it's not obvious - you only really need to care about this if you enable the packaging system on the target (i.e. "package-management" is in IMAGE_FEATURES). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto