On Sun, Mar 15, 2020 at 11:40 PM Mathias Kresin <d...@kresin.me> wrote: > > 05/03/2020 23:29, Alin Năstac: > > On Thu, Mar 5, 2020 at 8:34 PM Mathias Kresin <d...@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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
