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