Hi Michael,
On 06/04/2022 16:42, Michael Tremer wrote:
Hello Adolf,
On 6 Apr 2022, at 14:18, Adolf Belka adolf.belka@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@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.
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