Bug 5407

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)