I'm apparently a little shaky on exactly how the PR service is supposed
to work. I noticed an anomaly that adding a patch to SRC_URI for u-boot
did not result in a new package revision as I expected. I'm using
PRSERV_HOST="localhost:0" and have bulidhistory enabled.
I just tried this with a toy recipe named "hello" with a constant PR=r1
which does nothing but install a file from SRC_URI into ${datadir} with
this:
PR = "r1"
SRC_URI = " \
file://file1 \
"
S = "${WORKDIR}"
do_install () {
install -d ${D}/${datadir}/files
install file* ${D}/${datadir}/files
}
FILES_${PN} = "${datadir}/files/*"
I started with one file in SRC_URI, and "bitbake hello" produced
hello-1.0-r1.0.armv7a_vfp_neon.rpm as I expected.
I then added a second file to SRC_URI and re-ran "bitbake hello". The
recipe stages were re-executed, the new file was fetched and installed,
and I now have a hello-1.0-r1.0.armv7a_vfp_neon.rpm (same name) with
different contents. Build history confirms the differences in the
package FILELIST but no change to PKGR, as does dumping the rpm contents.
It is true that changing SRC_URI had no effect on the run.* task script
contents for the package, so it makes sense that the PR server doesn't
detect that the package is different from the last time it was built if
signatures from those scripts are the only way recipe changes are
detected. But it very much surprises me that changing the sources does
not result in a PR bump. In the normal work flow, adding a new patch to
SRC_URI is certainly something that I would expect to produce a new
package revision.
Is this how it's supposed to work?
Peter
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
