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

Yousong Zhou yszhou4tech at gmail.com
Wed Sep 5 23:04:45 EDT 2018


On Thu, 6 Sep 2018 at 11:00, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>
> 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.
> >

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

> > 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



More information about the openwrt-devel mailing list