Unexpected behavior from PR server

["Peter A. Bigot" <pab@pabigot.com>]

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