Re: libnfnetlink and libmnl

[Adolf Belka <adolf.belka@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

Hi Michael,

On 06/04/2022 17:38, Adolf Belka wrote:
> Hi Michael,
>
> On 06/04/2022 16:42, Michael Tremer wrote:
>> Hello Adolf,
>>
>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi All,
>>>
>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>
>> Oh this is very interesting.
>>
>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>
>> commit a10733a5d8580b6ab8cff46235daab6547723781
>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>> Date:   Thu Jan 3 14:27:11 2013 +0100
>>
>>      conntrack-tools: add conntrack and needed deps.
>>
>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.

It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.


I will continue looking through other files that you highlighted.


Regards,

Adolf.

>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>
>> See above.
>>
>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>
>> libaio
>> libart
>> libnet
>> libnl (and if something depends on it, can it not use libnl-3?)
>> libpri (if I remember correctly this was a dependency of asterisk)
>> libsolv can absolutely go for the moment, we don’t need it
>> netpbm?
>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>> sdparm
>>
>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
> I will give that a go and use your inputs as starting points.
>
> Regards,
> Adolf
>>
>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>
>> Best,
>> -Michael
>>
>>> Regards,
>>> Adolf
>>