On 27/02/2014 18:48, Paul Eggleton wrote: > On Thursday 27 February 2014 18:29:59 Alex J Lennon wrote: >> On 27/02/2014 18:18, Paul Eggleton wrote: >>> 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. >> OK so I can't download the source code to a distribution and built >> identical, identically versioned packages to theirs? With something like >> RPM wouldn't I expect to be able to download an RPM source package >> and build an identical, versioned RPM from it? > They'll always be "identical" as far as the material content goes, that's not > in question here - we're just talking about the PR values. For the PR values > it depends - which distro are we talking about? IIRC for example, SHR and > Angstrom both make their PR servers available so that people's PR values > will match up if they build it from source themselves. > > However, I think we're starting to head into territory where you have to > ask who is maintaining this distro you are referring to. If you're making > changes to how things get built, arguably it's now a derivative distro > and you ought to be maintaining it yourself; at which point you shouldn't > expect the PR values to match up. How else would you signify that you'd > made the configuration change (or added your own patch, or ...) if it's > someone else's distro that doesn't contain that change "upstream"? > >> Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to >> 2.0.0 to correspond to the upstream source versioning, and at that >> time I remove PR and build some packages. >> >> Then a month later I realise I need something extra added to the >> configuration options, which gives me a different output, what do I >> change to make sure the new package is versioned differently from >> the old package? (i.e. presumably if the network service is >> running it will handle it for me, but if it's not running then new >> package will be versioned identically to my old package?) > Yes. If you care about PR values (i.e. you're using packaging on the > target) then you need to enable and use the PR server. If you do that, > you don't need to make any additional change other than the > configure option change you've already made - EXTRA_OECONF > would presumably have been changed -> do_configure signature > changes -> dependent task signatures change -> the PR value > changes automatically. > >>>> 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. >> Must look at that, yes. > For reference: > > http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality > > Cheers, > Paul >
I've just noticed this which seems to usefully address some of my questions; include for others who may come across the thread, https://bugzilla.yoctoproject.org/show_bug.cgi?id=1556 Excellent. So I can export my current set of AUTOPR values to a file, give that to another development team in the handover, or test, or whomever, who can then import and build packages with the same version/name (assuming that they're on another site or otherwise don't have access to my PR network service ). I can see that will obviate the need for an inordinate number of conversations with the test team. _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto