On Wednesday 2024-10-16 21:04, Phil Sutter wrote:
>>
>> > We may increase incomplete marker correctness by treating support for
>> > any new attribute an incompatible update. Given that we often have
>> > dependencies between libnftnl and nftables for other things, it may not
>> > be too much of a downside though.
>>
>> 15:0:4 -> 16:0:5 means new API is available while older are still
>> supported, so old nftables can use this library binary safely.
>
>Yes, and my concern is if one installs this newer libnftnl, behaviour of
>incomplete marker will change despite the same old nftables package
>being in place which doesn't handle the new kernel attribute.
LIBVERSION is all about ABI/interface, not documented/observed behavior.
If, for example,
prime_factors@MATHLIB_v15(60000) yielded {2, 3, 5} but
prime_factors@MATHLIB_v16(60000) yields {2,2,2,2,2, 3, 5,5,5,5},
perhaps one should devise a new function name to capture the new behavior.
If a library merely passes through data from another entity (another library,
or in this case, the kernel), the function should have been specified
(documented) to potentially output unrecognized objects, and require of
any function users to deal with the situation amicably.
