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

[Yousong Zhou]

On Fri, 7 Sep 2018 at 04:37, Matthias Schiffer
<mschiffer at universe-factory.net> wrote:
>
> On 9/6/18 5:04 AM, Yousong Zhou wrote:
> > 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
>
> 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

Indeed.  I just checked the metadata.pm and found that it's actually a
"unshift" instead of what I used to thought as a "push".  That's the
better way of handling it.  Thank you.  I think this patch is not
needed then.

Regards,
                yousong

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