From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes To: development@lists.ipfire.org Subject: Re: libnfnetlink and libmnl Date: Thu, 07 Apr 2022 11:37:30 -0400 Message-ID: <8CE7430A-0250-4827-B68B-DACCBAB57A71@rymes.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3330525591559228032==" List-Id: --===============3330525591559228032== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Adolf, Is sdparm and/or lvm2 used by the =E2=80=9Cextra HD=E2=80=9D addon? Tom > On Apr 7, 2022, at 7:19 AM, Adolf Belka wrote: >=20 > =EF=BB=BFHi Michael & *, >=20 > Building without >=20 > libart > libdnet > libpri > libsolv > pigz > sdparm >=20 > went without any problems. I have submitted a patch set removing them from = IPFire. >=20 > libnet needs to stay as arping requires it. >=20 > libaio is needed by lvm2. However when I looked at lvm2 in IPFire it is not= actually used by IPFire at all. The commands are all available but there are= no mapped volume groups , logical groups etc. > Is lvm2 provided so that people can use logical volumes on additional hard = disks that might be mounted on IPFire. Presumably if people have already crea= ted lvm structures on other disk drives on the IPFire hardware then we need t= o stay with lvm2 being present otherwise its removal would stop people being = able to access that additional hard disk(s). > If that is the case then libaio will also need to stay. >=20 > Regards, > Adolf. >=20 >> On 06/04/2022 19:02, Michael Tremer wrote: >> 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 up= date 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 buil= d 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= and libnfnetlink for compiling/building different parts of libnetfilter_queu= e. I don't know if it is required for running but it wouldn't surprise me so = both these will have to stay. >>>=20 >>> It's interesting that the group that says libmnl should be used in prefer= ence to libnfnetlink then go and require both to still be used for one of the= ir programs. >> Well, we all have good intentions to keep our software clean, but very oft= en there is some legacy bit that everyone relies on and simply never gets cle= aned 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 lib= nfnetlink.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? >>>>>=20 >>>>> See above. >>>>>=20 >>>>> I believe there are a couple of other candidates for this which we shou= ld 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 = with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989) >>>>> sdparm >>>>>=20 >>>>> If you have the time, maybe you can have a look at what is used somewhe= re 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= should we carry around dead code? >>>>>=20 >>>>> Best, >>>>> -Michael >>>>>=20 >>>>>> Regards, >>>>>> Adolf --===============3330525591559228032==--