On 9/6/18 5:04 AM, Yousong Zhou wrote: > On Thu, 6 Sep 2018 at 11:00, Yousong Zhou <yszhou4t...@gmail.com> wrote: >> >> On Thu, 6 Sep 2018 at 04:15, Matthias Schiffer >> <mschif...@universe-factory.net> wrote: >>> >>> On 9/5/18 5:40 PM, Yousong Zhou wrote: >>>> The need arises when userspace package "openvswitch" selects >>>> "kmod-openvswitch" which will be provided by both "kmod-openvswitch" and >>>> "kmod-openvswitch-intree". In this case, we want it to prefer the >>>> package with the same name as with virtual package >>>> >>>> Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com> >>> >>> This patch should not be necessary: The implicit PROVIDES of a package name >>> by the package itself is handled by the "Package:" match, not the >>> "Provides:" match in metadata.pm, so the package itself should always be at >>> the front of $vdep. >>> > > When both kmod-openvswitch and kmod-openvswitch-intree provides > virtual package "kmod-openvswitch", it's possible that future changes > to metadata generation will have "kmod-openvswitch-intree" in the > front of provides list. I'd like to make it explicit predictable > that the package with the same name is always more preferable by the > build system. > > Regards, > yousong
This is precisely what my metadata changes that were merged a few months ago achieved (besides some general cleanup): we can now PROVIDE an existing package; in such a case the original package is preferred, as it is explicitly added at the front of the vdeps list (while providers added through PROVIDES are added to the end). The usecase you describe is already supported, and handled as expected (unless I'm overlooking something). Regards, Matthias > >>> Are you dealing with a broken package Makefile that defines an explicit >>> PROVIDES for itself? PATCH 1/1 also seems to deal with a case that should >>> not exist (and IMO we should rather filter such things out with a warning >>> in metadata generation, not in metadata parsing). >> >> The use case is new when trying to offer two flavors of openvswitch >> datapath modules. The "kmod-openvswitch" is already there, and >> "kmod-openvswitch-intree" is the name of to-be-introduced package. >> >> After seeing that "Provides:" field value is empty by default in >> "tmp/info/.packageinfo-feeds_packages_openvswitch" and only >> implemented implicitly by metadata.pm script, I think the better way >> of handling this would be making the metadata.pm script more robust by >> accommodate the use case (otherwise additional checks will need to be >> implemented by packagers on their own). >> >>> Can you give me a pointer to the two Makefiles that cause such an issue >>> (where does kmod-openvswitch-intree come from)? >> >> Relevant line at pull request: >> https://github.com/openwrt/packages/pull/6955/files#diff-c534883bd64120316db4902f23812872R57 >> >> Regards, >> yousong
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
