[yocto] clarify instructions for package feed installation

[Peter A. Bigot]

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