From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: libnfnetlink and libmnl Date: Thu, 07 Apr 2022 17:59:37 +0200 Message-ID: <09bab0ec-986c-dd77-c0cd-4e947bcc2c77@ipfire.org> In-Reply-To: <7F88BEBB-3E31-4F35-9FA0-A6E785DCA25E@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4109195566925158035==" List-Id: --===============4109195566925158035== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I just had a detailed look through extrahd.cgi and extrahd.pl and scanhd and = neither lvm nor sdparm are used. Basically the ExtraHD entry uses data from fstab and searching in /sys/block/= ... to find info about disks and partitions. Regards, Adolf. On 07/04/2022 17:53, Michael Tremer wrote: > I couldn=E2=80=99t find anything using this either. Happy to be corrected i= f I am wrong :) >=20 >> On 7 Apr 2022, at 16:43, Adolf Belka wrote: >> >> Hi Tom, >> >> >> On 07/04/2022 17:37, Tom Rymes wrote: >>> Adolf, >>> Is sdparm and/or lvm2 used by the =E2=80=9Cextra HD=E2=80=9D addon? >> >> It didn't show up with a grep of the IPFire git repository. I will have a = further look into it to see if they are needed to run it. >> >> Regards, >> Adolf. >>> Tom >>>> On Apr 7, 2022, at 7:19 AM, Adolf Belka wrote: >>>> >>>> =EF=BB=BFHi Michael & *, >>>> >>>> Building without >>>> >>>> libart >>>> libdnet >>>> libpri >>>> libsolv >>>> pigz >>>> sdparm >>>> >>>> went without any problems. I have submitted a patch set removing them fr= om IPFire. >>>> >>>> libnet needs to stay as arping requires it. >>>> >>>> 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 ha= rd disks that might be mounted on IPFire. Presumably if people have already c= reated lvm structures on other disk drives on the IPFire hardware then we nee= d to stay with lvm2 being present otherwise its removal would stop people bei= ng able to access that additional hard disk(s). >>>> If that is the case then libaio will also need to stay. >>>> >>>> Regards, >>>> Adolf. >>>> >>>>> On 06/04/2022 19:02, Michael Tremer wrote: >>>>> Hello, >>>>>>> On 6 Apr 2022, at 17:52, Adolf Belka wrote: >>>>>> >>>>>> 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 wro= te: >>>>>>>>> >>>>>>>>> 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 libnfnetli= nk 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 comm= it: >>>>>>>> >>>>>>>> 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 b= uild 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 lib= mnl and libnfnetlink for compiling/building different parts of libnetfilter_q= ueue. 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 pre= ference 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 = cleaned up. >>>>>> I will continue looking through other files that you highlighted. >>>>> Thank you. >>>>>> >>>>>> >>>>>> 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 usa= ge of libnfnetlink to libmnl? >>>>>>>> >>>>>>>> See above. >>>>>>>> >>>>>>>> I believe there are a couple of other candidates for this which we s= hould 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=E2=80=99t need it >>>>>>>> netpbm? >>>>>>>> pigz (we don=E2=80=99t use it anywhere since we are compressing imag= es with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989) >>>>>>>> sdparm >>>>>>>> >>>>>>>> If you have the time, maybe you can have a look at what is used some= where and what can be dropped? >>>>>>> I will give that a go and use your inputs as starting points. >>>>>>> >>>>>>> Regards, >>>>>>> Adolf >>>>>>>> >>>>>>>> This won=E2=80=99t shrink the distribution by a massive amount, but = why should we carry around dead code? >>>>>>>> >>>>>>>> Best, >>>>>>>> -Michael >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Adolf >=20 --===============4109195566925158035==--