Create a standard way of adding feeds to be written into the package manager configuration in the final image (when package-management is in IMAGE_FEATURES). We have IPK_FEED_URIS, but that is specific to ipk - we should probably add counterparts for RPM and DEB.
Also, there is some ipk-specific code for a FEED_URIS variable in image.bbclass in addition to IPK_FEED_URIS handling in rootfs_ipk.bbclass; this should be tidied up.
Also worth referring to is distro-feed-configs.bb in meta-oe.
And poky-feed-config-opkg in oe-core.
*** Bug 5435 has been marked as a duplicate of this bug. ***
The deb/rpm/ipkg all supported by the following patch: Author: David Nyström <david.c.nystrom@gmail.com> Date: Thu Feb 27 21:20:37 2014 +0100 do_rootfs: Added PACKAGE_FEED_URIS functionality Adding a common interface to add predefined package manager channels to prebuilt rootfs:es. Adding PACKAGE_FEED_URIS = "http://myre.po/repo/, will assume repo directories named (rpm,ipk,deb) as subdirectories and statically add them to the rootfs, using the same PKG_ARCHs as the build which produced the images. Tested with RPM, IPK and DEB. deb feed functionality seem broken, is anyone using this ? (From OE-Core rev: 9b8811045546ad67b4695d980f09636d5506e50c) We should clean up the duplicated configs: IPK_FEED_URIS/ PACKAGE_FEED_URIS/ BUILD_IMAGES_FROM_FEEDS/ FEED_URIS/ FEED_DEPLOYDIR_BASE_URI //Hongxu
The deb/rpm/ipkg all supported by the following patch: Author: David Nyström <david.c.nystrom@gmail.com> Date: Thu Feb 27 21:20:37 2014 +0100 do_rootfs: Added PACKAGE_FEED_URIS functionality Adding a common interface to add predefined package manager channels to prebuilt rootfs:es. Adding PACKAGE_FEED_URIS = "http://myre.po/repo/, will assume repo directories named (rpm,ipk,deb) as subdirectories and statically add them to the rootfs, using the same PKG_ARCHs as the build which produced the images. Tested with RPM, IPK and DEB. deb feed functionality seem broken, is anyone using this ? (From OE-Core rev: 9b8811045546ad67b4695d980f09636d5506e50c)
It's taken me far too long to respond to this - sorry about that. I think PACKAGE_FEED_URIS is definitely a start, however I think it has some limitations that make it difficult to use in the general case - for example, it hardcodes that the feed will be under /rpm/ or /ipk/ under the specified URI, and that the feed will be split by architecture and nothing else - that's all well and good if all you care about is testing directly pointing to the output of tmp/deploy, but otherwise you might not be prepared to live with those limitations. Whatever mechanism we have, it ought to be able to replace the existing ones. We still have IPK_FEED_URIS and distro-feed-configs in meta-oe for example, I'd like to think we can have something in OE-Core so both of those can be removed. Reopening and assigning to me for now - if someone else wants to take it then I'd be happy for that to happen.
(In reply to comment #7) > It's taken me far too long to respond to this - sorry about that. > > I think PACKAGE_FEED_URIS is definitely a start, however I think it has some > limitations that make it difficult to use in the general case - for example, > it hardcodes that the feed will be under /rpm/ or /ipk/ under the specified > URI, and that the feed will be split by architecture and nothing else - > that's all well and good if all you care about is testing directly pointing > to the output of tmp/deploy, but otherwise you might not be prepared to live > with those limitations. > > Whatever mechanism we have, it ought to be able to replace the existing > ones. We still have IPK_FEED_URIS and distro-feed-configs in meta-oe for > example, I'd like to think we can have something in OE-Core so both of those > can be removed. > > Reopening and assigning to me for now - if someone else wants to take it > then I'd be happy for that to happen. I got a patch (locally, not sent yet to the ML) which uses PACKAGE_FEED_URIS AND a new variable called PACKAGE_FEED_PREFIX to create a full URI. Also, I removed all the hard-coded /rpm/, /ipk/ and /deb/ sub-strings on the links mentioned in your comment. Should I remove the IPK_FEED_URIS feature completely? I think we should, and just have one way to include package feeds no matter what the package manager is.
Patch sent to the ML. From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Subject: [PATCH] lib/oe/package_manager: Include PACKAGE_FEED_PREFIX instead of hardcode paths Instead of hardcode paths (/rpm/, /ipk/, /deb/), use a user-defined prefix when creating the URI feeds. URIs now will have the following syntax: PACKAGE_FEED_URIS_1/PACKAGE_FEED_PREFIX PACKAGE_FEED_URIS_2/PACKAGE_FEED_PREFIX . where PACKAGE_FEED_URIS = "PACKAGE_FEED_URIS_1 PACKAGE_FEED_URIS_2 ...." [YOCTO #5407]
Patch merged on master 338c325: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=338c3257f60e99c1fd101d5010daea4099eb1d0e
Patch includes code changes. what about documentation changes to document that new behaviour in developer manual ?
(In reply to comment #11) > Patch includes code changes. what about documentation changes to document > that new behaviour in developer manual ? You are completely right. I will file a bug about it.
(In reply to comment #11) > Patch includes code changes. what about documentation changes to document > that new behaviour in developer manual ? There is now a bug about documenting the feature https://bugzilla.yoctoproject.org/show_bug.cgi?id=8301
The patch did not solve the problem completely: there are two more points to consider. 1) instead of a single PREFIX variable, we should have something like PACKAGE_FEED_PREFIXES = "/rpm/core2_64 /rpm/all ..." so there is a bit more flexibility to the user (with current implementation ALL URL share the same PREFIX) 2) PREFIX(S) name should be reconsider: SUFFIX(S) can be a better name, because it is actually a suffix inside the FEED.
New patch sent to the ML: http://lists.openembedded.org/pipermail/openembedded-core/2015-October/111297.html In resume: FEED_PREFIX was rename to FEED_BASE_PATHS and FEED_ARCHS new variable created. More info on patch's description.
Merge into master branch (6650357)