On 03/16/2018 05:27 AM, Alexander Kanavin wrote:
On 03/15/2018 10:10 PM, Peter A. Bigot wrote:
Following the instructions in the 2.4.2 mega-manual section 4.21.4 I set
in local.conf:
PACKAGE_FEED_URIS = "http://192.168.65.22/oe/rpi3-sumo";
PACKAGE_FEED_BASE_PATHS = "rpm"
PACKAGE_FEED_ARCHS = "noarch cortexa7hf_neon_vfpv4 raspberrypi3"
and run this command:
bitbake package-index
This produces a repodata directory in the deploy/rpm directory, sibling
to the arch directories.
drwxr-xr-x 2 pab pab 516096 Mar 15 12:26 cortexa7hf_neon_vfpv4
drwxr-xr-x 2 pab pab 24576 Mar 15 12:55 noarch
drwxr-xr-x 2 pab pab 262144 Mar 15 12:26 raspberrypi3
drwxr-xr-x 2 pab pab 4096 Mar 15 15:02 repodata
However, the repo file generated by the PACKAGE_FEED variables causes
dnf on the target to fetch repodata from inside each arch directory:
192.168.65.117 - - [15/Mar/2018:14:03:18 -0500] "GET
/oe/rpi3-sumo/rpm/noarch/repodata/repomd.xml HTTP/1.1" 404 481 "-"
"dnf/2.7.5"
192.168.65.117 - - [15/Mar/2018:14:05:51 -0500] "GET
/oe/rpi3-sumo/rpm/raspberrypi3/repodata/repomd.xml HTTP/1.1" 404 487
"-" "dnf/2.7.5"
192.168.65.117 - - [15/Mar/2018:14:05:51 -0500] "GET
/oe/rpi3-sumo/rpm/cortexa7hf_neon_vfpv4/repodata/repomd.xml HTTP/1.1"
404 496 "-" "dnf/2.7.5"
This doesn't work. I end up having to change the repo file to eliminate
the architectures.
Is this a problem specific to RPM, or am I doing something wrong?
I think the documentation is misleading here. 'bitbake package-index'
generates a single index for all of the architectures in the
deploy/rpm directory, so if you need individual feeds for specific
architectures, you need to generate them yourself with a custom
recipe. Or if you're okay with having a single index, just drop the
PACKAGE_FEED_ARCHS setting.
CC Scott, so we can add a note for RPM feeds in the docs here.
Alex
Thanks; that makes sense. A documentation note that PACKAGE_FEED_ARCHS
should only be used if indexes are generated a different way would be
worthwhile. AFAICT the only time identifying specific architectures is
useful is in filtering irrelevant candidates when multiple architectures
are present. It's not immediately obvious how to put multiple
incompatible archs into the same hierarchy anyway unless something
automatically reconciles the companion noarch packages that get produced
in builds for different MACHINEs.
Peter
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
