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

[Matthias Schiffer]

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


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20180906/121c8629/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel