Bug 12419

Amanda: Were you able to make it work if you changed the path? For Scott to fix this we likely need to help him understand what the steps should be to make this work.

Richard: Yes; if I change the base url to http://my.server instead of http://my.server/rpm/i586, it works.

Amanda and Richard, 

Please look at http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#runtime-package-management-target-rpm and let me know if this changes takes care of the issue. 

Thanks, 
Scott

Scott: Yes, this fixed the issue. Thanks.

Setting status to RESOLVED and marking Doc Flag as Done. Thanks!

Currently we have a defect in rpm package indexing, it creates only a top level index that includes all of the architectures, but does not create architecture-specific indexes. I'm working on a patch that addresses that, which should be available shortly.

Meanwhile, please fix the manual to give the user two choices:

1. An explicit list of architectures (currently broken, will be fixed shortly):

[oe-packages]
baseurl=http://my.server/rpm/i586 http://my.server/rpm/qemux86 http://my.server/rpm/all

2. A full package index:

[oe-packages]
baseurl=http://my.server/rpm

Add a note that any listed URL should have 'repodata' directory in it (which contains the package index), so the web server should be set up accordingly.

Mixing the two like the manual currently does is not correct.

Patch sent, now only the manual needs to be fixed:

http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148908.html

I have a final version of the runtime package management stuff and a bit of a re-write for the PACKAGE_FEEDS_ARCHS variable.  Maybe you could review these sections for sanity.

Thanks,
Scott

https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_FEED_ARCHS - Here, I added wording to show this is an optional variable.  I also put in a "Tip" box to describe the ability to "whitelist" architectures.

https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#using-runtime-package-management - I updated the example list of bash packages created by a build.  I previously had a static list that was not complete.  Wording now lists a bunch of bash packages as an example.

https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#runtime-package-management-build - I added "tar" as a supported package.  It was not in the previous list but is mentioned in the description of the PACKAGE_CLASSES variable.  I added better wording about generating the package index.  I understand the dependency issues here now so I think was able to better explain to the user the need for building the package index separately after any packages are built. 

https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#runtime-package-management-target-rpm - I pretty much rewrote this entire section for clarity and better understanding.

1.

"Omitting the variable results in the package feed URI consisting of the PACKAGE_FEED_URIS and PACKAGE_FEED_BASE_PATHS parts only (i.e. all architectures included in a single location). "

This actually depends on the package manager in use. I think rpm will use a single global feed with a single index, but deb/opkg will explicitly list all of the architecture-specific feeds, each coming with their own index. Anyway, it's an implementation detail and subject to change.

It's better to say:
"Omitting the variable results in all available architectures for the current machine being included into remote package feeds."

2.

"Furthermore, the example assumes a typical production scenario where the the developer runs a web server that takes the index and the packages directly from a location outside of the build system's deploy directory. Realize that it is possible to run a web server that gets the databases from deploy directory where the image was built. "

Actually, nothing in the example assumes that. It will work regardless of how the web server is set up. You should change the wording to explain that the specifics of setting up a web server are up to the user (and present the two options for it), the only thing that's important is that the uris in the repository configuration on target point to the correct remote location.

3.

"This example informs DNF about individual package databases for all three architectures. Using individual locations per architecture involves using the PACKAGE_FEED_ARCHS variable. "
and
"This example informs DNF about a single package database that contains all the package index information for all supported architectures. Using a single location for all architectures results when you do not use the PACKAGE_FEED_ARCHS variable. "

PACKAGE_FEED_ARCHS variable has no influence on how the package index is generated. The index will be the same (one global index, and several per-architecture indexes) regardless of how the variable is set. PACKAGE_FEED_ARCHS influences only how the repository configuration on target is generated (which we don't do here, as we explain how to do the same thing manually). Long story, short, I think you can just drop the second sentences from both of these paragraphs.

Other than that, LGTM. Cheers!

Thanks Alex, 

Point 1 - see https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_FEED_ARCHS for the change.

Point 2 - see https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#runtime-package-management-target-rpm in the 3rd paragraph for the change.

Point 3 - See https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#runtime-package-management-target-rpm and the two bulleted items.  I removed those sentences as you suggested. 

Let me know if this works and I will close the bug.

Thanks, 
Scott

Nearly there :)

"This example uses a location outside of the build system's deploy directory. Realize that it is possible to run a web server that gets the databases from deploy directory where the image was built. "

If the example was using a location inside the deploy directory, it would actually look just the same. Maybe it's better to say:

"The web server can be pointed to the build system's deploy directory for development purposes, but for production use it's better to copy the package directories to a different location and use that, as the files in the deploy directory can be changed or overwritten by bitbake as a part of the development process".

Oh, and you can add a tip about how to start a web server:

"For development purposes, you can start a web server with Python. The following would run a server on port 8000, serving files relative to the current directory (for example, the packages deploy directory).

# python3 -m http.server 8000

More information: https://docs.python.org/3/library/http.server.html

Do note that this 'server' is not able to handle anything more than a very light load, and for production use you need to replace it with a commercial-grade solution."

Ah, never mind, it's already in section 4.23.4.2. :)

Alex, 

I took some literary license here and decided to actually turn that nugget of information into a boxed "Tip".  It sort of seems like an aside anyway.  Please check it and let me know of any other problems. 

Thanks, 
Scott

https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#runtime-package-management-target-rpm

Cool, I think we're good now.

Awesome ... I am marking as RESOLVED and putting the doc flag to "done."

Thanks for all your help.

Scott