From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: libnfnetlink and libmnl Date: Wed, 06 Apr 2022 18:02:33 +0100 Message-ID: In-Reply-To: <23823e37-ef7e-eae7-015c-4dd6a018d3ea@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3755707056148933245==" List-Id: --===============3755707056148933245== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 6 Apr 2022, at 17:52, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 06/04/2022 17:38, Adolf Belka wrote: >> Hi Michael, >>=20 >> On 06/04/2022 16:42, Michael Tremer wrote: >>> Hello Adolf, >>>=20 >>>> On 6 Apr 2022, at 14:18, Adolf Belka wrote: >>>>=20 >>>> Hi All, >>>>=20 >>>> We have both libnfnetlink and libmnl in IPFire. I have just done an upda= te of libmnl. >>>> There is an update of libnfnetlink but it also says that libnfnetlink is= still deprecated and should preferably be replaced by libmnl >>>=20 >>> Oh this is very interesting. >>>=20 >>> It looks like libmnl was introduced for conntrack-tools in this commit: >>>=20 >>> commit a10733a5d8580b6ab8cff46235daab6547723781 >>> Author: Arne Fitzenreiter >>> Date: Thu Jan 3 14:27:11 2013 +0100 >>>=20 >>> conntrack-tools: add conntrack and needed deps. >>>=20 >>> 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. >>>=20 > It didn't go clean. It looks like libnetfilter_queue requires both libmnl a= nd 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 bo= th these will have to stay. >=20 > It's interesting that the group that says libmnl should be used in preferen= ce to libnfnetlink then go and require both to still be used for one of their= programs. Well, we all have good intentions to keep our software clean, but very often = there is some legacy bit that everyone relies on and simply never gets cleane= d up. > I will continue looking through other files that you highlighted. Thank you. >=20 >=20 > Regards, >=20 > Adolf. >=20 >>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnf= netlink.so.0.2.0 and neither came up with anything. Doing a grep on the git r= epository 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? >>>=20 >>> See above. >>>=20 >>> 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: >>>=20 >>> 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=E2=80=99t need it >>> netpbm? >>> pigz (we don=E2=80=99t use it anywhere since we are compressing images wi= th XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989) >>> sdparm >>>=20 >>> 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. >>=20 >> Regards, >> Adolf >>>=20 >>> This won=E2=80=99t shrink the distribution by a massive amount, but why s= hould we carry around dead code? >>>=20 >>> Best, >>> -Michael >>>=20 >>>> Regards, >>>> Adolf --===============3755707056148933245==--