| Summary: | Small suggested version/revision-related clarifications | ||
|---|---|---|---|
| Product: | [Documentation] Reference | Reporter: | ulfalizer |
| Component: | handbook | Assignee: | Scott Rifenbark <srifenbark> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | bluelightning, poky.doc.watcher, poky.watcher, sgw, srifenbark |
| Version: | 2.2 | ||
| Target Milestone: | 2.2 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | 22 August 2016: RESOLVED | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Done (doc changes complete) | |
|
Description
ulfalizer
2016-08-13 06:51:48 UTC
Guess the checksum link within the same manual could be used instead: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#checksums Kinda ugly how that section is (more or less) duplicated in both manuals. Cheers, Ulf Hmm... I think I prefer the version in the BitBake User Manual though, so never mind. The one in the reference manual makes it sound like the checksums are only about the sstate cache, but they're also used to determine if non-sstate tasks should be rerun. Cheers, Ulf Hi Ulf, Have not been able to get to these until now. Been busy in the Eclipse world :( See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PKGV for the PKGV change. See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PV for the PV change. See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PE for the PE change. See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PR for the PR note change. For the reference to "stamp", I left it unformatted as the actual name of the directory seems to be "stamps". So I figured it was a general reference to that particular mechanism. BTW - there is some duplication between the BitBake manual and the YP reference manual. One thing we do not do is reference from the BB manual into any YP manuals. We do, however, reference from YP manuals into the BB manual. Sometimes topics differ between the two manuals. I don't know if that is the case here. It might just be the same information with the BB version being better. I will look into that. Scott Hello, (In reply to comment #3) > Hi Ulf, > > Have not been able to get to these until now. Been busy in the Eclipse > world :( No worries. For a while I thought you were on vacation. :) > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PKGV > for the PKGV change. "The version of the package(s) built by the recipe" would be better since a recipe can build more than one package. "Output package" is a bit redundant in retrospect, so I removed the "output" part too. > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PV > for the PV change. Looks good to me. > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PE > for the PE change. Looks good. One more suggested change: To make the PKGE glossary entry consistent with PKGV, the beginning could be changed to this: The epoch of the package(s) built by the recipe. > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PR > for the PR note change. For the reference to "stamp", I left it unformatted > as the actual name of the directory seems to be "stamps". So I figured it > was a general reference to that particular mechanism. Yeah, that makes sense to me. The same change as mentioned above for PKGE could be made for PKGR too, changing the beginning to the following: The revision of the output package(s) built by the recipe. > BTW - there is some duplication between the BitBake manual and the YP > reference manual. One thing we do not do is reference from the BB manual > into any YP manuals. We do, however, reference from YP manuals into the BB > manual. Sometimes topics differ between the two manuals. I don't know if > that is the case here. It might just be the same information with the BB > version being better. I will look into that. I think it's mostly that the BB manual doesn't talk as much about the sstate cache. I guess that makes sense in a way, since most of the sstate logic is implemented at a higher level. BitBake itself only provides the basic setscene magic. I prefer the BB manual in this case, since task checksums aren't just for determining if sstate tasks need to be rerun. Cheers, Ulf (In reply to comment #4) > Hello, > > (In reply to comment #3) > > Hi Ulf, > > > > Have not been able to get to these until now. Been busy in the Eclipse > > world :( > > No worries. For a while I thought you were on vacation. :) > > > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PKGV > > for the PKGV change. > > "The version of the package(s) built by the recipe" would be better since a > recipe can build more than one package. "Output package" is a bit redundant > in retrospect, so I removed the "output" part too. Ok - changed that. > > > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PV > > for the PV change. > > Looks good to me. > > > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PE > > for the PE change. > > Looks good. > > One more suggested change: To make the PKGE glossary entry consistent with > PKGV, the beginning could be changed to this: > > The epoch of the package(s) built by the recipe. Changed that also. > > > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PR > > for the PR note change. For the reference to "stamp", I left it unformatted > > as the actual name of the directory seems to be "stamps". So I figured it > > was a general reference to that particular mechanism. > > Yeah, that makes sense to me. > > The same change as mentioned above for PKGE could be made for PKGR too, > changing the beginning to the following: > > The revision of the output package(s) built by the recipe. Changed that as well. > > > BTW - there is some duplication between the BitBake manual and the YP > > reference manual. One thing we do not do is reference from the BB manual > > into any YP manuals. We do, however, reference from YP manuals into the BB > > manual. Sometimes topics differ between the two manuals. I don't know if > > that is the case here. It might just be the same information with the BB > > version being better. I will look into that. > > I think it's mostly that the BB manual doesn't talk as much about the sstate > cache. I guess that makes sense in a way, since most of the sstate logic is > implemented at a higher level. BitBake itself only provides the basic > setscene magic. > > I prefer the BB manual in this case, since task checksums aren't just for > determining if sstate tasks need to be rerun. > > Cheers, > Ulf Getting slightly OCD now, but PKGR still says "output package(s)" rather than just "package(s)". :P Looks fine other than that, Ulf LGTM :) Set to RESOLVED and put doc flag to "done." scott |