[OpenWrt-Devel] [PATCH] iproute2: revert add libcap support, enabled in ip-full

[Alin Năstac]

On Sun, Mar 15, 2020 at 11:40 PM Mathias Kresin <dev at kresin.me> wrote:
>
> 05/03/2020 23:29, Alin Năstac:
> > On Thu, Mar 5, 2020 at 8:34 PM Mathias Kresin <dev at kresin.me> wrote:
> >>
> >> This reverts commit a6da3f9ef746101b84a6f530f5a40de28341b69a.
> >
> > Not exactly a revert, since it keeps HAVE_CAP logic.
>
> Sure, I want to make sure that HAVE_CAP is really disabled.
>
> >> The libcap isn't as optional as the commit messages suggests. A hard
> >> dependency to the libcap package is added, which is only available in
> >> the external packages feed. Therefore it is impossible to package
> >> ip-full without having the external packages feed up and running, which
> >> is a regression to the former behaviour.
> >
> > The libcap support is by all means optional, otherwise iproute2 build
> > will fail when its missing.
>
> You describe exactly the issue I hit while building ip-full. During
> development I don't have any external/third-party feeds installed. And
> the OpenWrt base system shouldn't depend on external/third-party feeds.
> These feeds are an add on and by no means a requirement.
>
> > Besides, your commit actually removes this
> > dependency. If this is not a living proof of the facultative nature of
> > this dependency, I don't know what else is.
>
> Sorry, I don't get what you're trying to say.

I'm trying to say that libcap dependency is optional from iproute2 tarball pov.

I guess you were trying to say that openwrt +libcap dependency was not
optional, but I don't really understand why you think it isn't. ip
package has 2 variants (tiny and full) and I only enabled it on
ip-full variant.Since the variant selection is at user's discretion,
the ip openwrt package dependency of libcap *is* - by all means of the
word - optional.

> > One would argue that ip-full should correspond to the full fledged
> > version of the packet. If the dependency of an external package is the
> > issue, how about making a different variant with HAVE_CAP support? It
> > could be called ip-really-full (or ip-fullest).
>
> Try to get libcap into the OpenWrt base system and enable HAVE_CAP
> afterwards?

As I said in the previous message, my use case doesn't require libcap
functionality, so I have no problem with disabling HAVE_CAP in the
full variant, but from the semantic pov, full should really mean "all
functionality enabled". Maybe it would be wise to create a third
variant called standard that would be equivalent with the full variant
minus HAVE_CAP.

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