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
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?
Regards, Adolf
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?
This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
Best, -Michael
Regards, Adolf
On Apr 6, 2022, at 10:42 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello Adolf,
[snip]
libpri (if I remember correctly this was a dependency of asterisk)
[snip]
libpri should be a dependency of dahdi, which is a dependency of asterisk.
Tom
Thanks for chiming in. That is what I thought and we don’t have asterisk any more. So it can very likely go, too.
On 6 Apr 2022, at 16:20, Tom Rymes tom@rymes.net wrote:
On Apr 6, 2022, at 10:42 AM, Michael Tremer michael.tremer@ipfire.org wrote:
Hello Adolf,
[snip]
libpri (if I remember correctly this was a dependency of asterisk)
[snip]
libpri should be a dependency of dahdi, which is a dependency of asterisk.
Tom
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
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 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.
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and 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 both these will have to stay.
It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.
I will continue looking through other files that you highlighted.
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 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
Hello,
On 6 Apr 2022, at 17:52, Adolf Belka adolf.belka@ipfire.org 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 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.
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and 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 both these will have to stay.
It's interesting that the group that says libmnl should be used in preference 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 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
Hi Michael & *,
Building without
libart libdnet libpri libsolv pigz sdparm
went without any problems. I have submitted a patch set removing them from 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 hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to 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.
Regards, Adolf.
On 06/04/2022 19:02, Michael Tremer wrote:
Hello,
On 6 Apr 2022, at 17:52, Adolf Belka adolf.belka@ipfire.org 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 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.
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and 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 both these will have to stay.
It's interesting that the group that says libmnl should be used in preference 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 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
Adolf,
Is sdparm and/or lvm2 used by the “extra HD” addon?
Tom
On Apr 7, 2022, at 7:19 AM, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael & *,
Building without
libart libdnet libpri libsolv pigz sdparm
went without any problems. I have submitted a patch set removing them from 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 hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to 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.
Regards, Adolf.
On 06/04/2022 19:02, Michael Tremer wrote: Hello,
On 6 Apr 2022, at 17:52, Adolf Belka adolf.belka@ipfire.org 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 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.
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and 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 both these will have to stay.
It's interesting that the group that says libmnl should be used in preference 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 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
Hi Tom,
On 07/04/2022 17:37, Tom Rymes wrote:
Adolf,
Is sdparm and/or lvm2 used by the “extra HD” 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 adolf.belka@ipfire.org wrote:
Hi Michael & *,
Building without
libart libdnet libpri libsolv pigz sdparm
went without any problems. I have submitted a patch set removing them from 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 hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to 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.
Regards, Adolf.
On 06/04/2022 19:02, Michael Tremer wrote: Hello,
On 6 Apr 2022, at 17:52, Adolf Belka adolf.belka@ipfire.org 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 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.
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and 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 both these will have to stay.
It's interesting that the group that says libmnl should be used in preference 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 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
I couldn’t find anything using this either. Happy to be corrected if I am wrong :)
On 7 Apr 2022, at 16:43, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Tom,
On 07/04/2022 17:37, Tom Rymes wrote:
Adolf, Is sdparm and/or lvm2 used by the “extra HD” 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 adolf.belka@ipfire.org wrote:
Hi Michael & *,
Building without
libart libdnet libpri libsolv pigz sdparm
went without any problems. I have submitted a patch set removing them from 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 hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to 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.
Regards, Adolf.
On 06/04/2022 19:02, Michael Tremer wrote: Hello,
On 6 Apr 2022, at 17:52, Adolf Belka adolf.belka@ipfire.org 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 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. >
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and 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 both these will have to stay.
It's interesting that the group that says libmnl should be used in preference 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 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
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’t find anything using this either. Happy to be corrected if I am wrong :)
On 7 Apr 2022, at 16:43, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Tom,
On 07/04/2022 17:37, Tom Rymes wrote:
Adolf, Is sdparm and/or lvm2 used by the “extra HD” 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 adolf.belka@ipfire.org wrote:
Hi Michael & *,
Building without
libart libdnet libpri libsolv pigz sdparm
went without any problems. I have submitted a patch set removing them from 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 hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to 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.
Regards, Adolf.
On 06/04/2022 19:02, Michael Tremer wrote: Hello,
> On 6 Apr 2022, at 17:52, Adolf Belka adolf.belka@ipfire.org 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 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. >> It didn't go clean. It looks like libnetfilter_queue requires both libmnl and 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 both these will have to stay.
It's interesting that the group that says libmnl should be used in preference 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 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
-
Adolf Belka -
Michael Tremer -
Tom Rymes