[OpenWrt-Devel] [PATCH 2/2] scripts/package-metadata.pl: prefer $vdep with the same name as $depend

[Yousong Zhou]

On Thu, 6 Sep 2018 at 04:15, Matthias Schiffer
<mschiffer at 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 <yszhou4tech at 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.
>
> 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

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel