optimizing: 'config.in' macros

[skrab-sah]

AF_UNIX <- HAVE_AFUNIX.
AF_INET <- HAVE_AFINET.
AF_INET6 <- HAVE_AFINET6.
AF_IPX <- HAVE_AFIPX.
AF_APPLETALK <- HAVE_AFATALK.
AF_NETROM <- HAVE_AFNETROM.
AF_AX25 <- HAVE_AFAX25.
AF_ROSE <- HAVE_AFROSE.
AF_X25 <- HAVE_AFX25.
AF_ECONET <- HAVE_AFECONET.
AF_ASH <- HAVE_AFASH.

[ecki]

I think the intention of separating the header defines and the config defines was to make it configurable and especially to allow to produce pruned down binaries.

I am not sure if this is still required but I am hesitant to change it since we had a lot of compatibility problems with compiling on different distributions and kernel sources. (And additional headers for the more esoteric protocols)

i do see the advantage of not failing compilation with a wrong config (however the default should be fine and not trigger that anymore)

i will see what the mailing list things, in any case it would be good if we can change the commit message into something like „Detect compile protocols instead of config.in“ or something along this line.

[skrab-sah]

I am not sure if this is still required but I am hesitant to change it since we had a lot of compatibility problems with compiling on different distributions and kernel sources. (And additional headers for the more esoteric protocols)

We can separate it by distributions and kernel pre-defined macros.

I think the intention of separating the header defines and the config defines was to make it configurable and especially to allow to produce pruned down binaries.

We can specify an option in Makefile to create kernel specific binary.

i do see the advantage of not failing compilation with a wrong config (however the default should be fine and not trigger that anymore)

i will see what the mailing list things, in any case it would be good if we can change the commit message into something like „Detect compile protocols instead of config.in“ or something along this line.

want mailing list link.

[ecki]

The mailing list is here https://sourceforge.net/p/net-tools/mailman/

[ecki]

We can specify an option in Makefile to create kernel specific binary.

we could but I don’t see the point of spending so much time to redesign a basically EOL package - at least I don’t have the motivation to deal with the fallout of distributions complain about changed built environment.

[skrab-sah]

we could but I don’t see the point of spending so much time to redesign a basically EOL package - at least I don’t have the motivation to deal with the fallout of distributions complain about changed built environment.

As per me,
There is not too many work to do, a little bit changes.

If you could provide me supported list of kernel version and distribution.

What EOL package means. (Is net-tools deprecated)

[ecki]

Yes net-Tools is deprecated, iproute2 is the official successor for most of the tools. This is mainly because it does not use the outdated/limited proc/ioctl interfaces, so it has more features and better performance.

I don’t have a list of versions, in fact every time I try another kernel/distribution combination causes problems. I think we should check with Debian, ubuntu, fedora and opensuse (always latest rolling)

I am glad that Debian and Redhat maintains forks themself and we try to incorporate the changes to the upstream, i don’t want to complicate their life with build system changes or changes to default config. Having said that, if they would feel it help them it’s fine with me, but I expect most use either a hardcoded feature list or go with the default.

having said that, did you check with your patch in place are there changes to the feature list compared to config defaults? If I remeber correctly the defaults did not enable all protocols purely based on the grade of feature-completeness or usage.