Re: [ANNOUNCE] ipset 6.5 released

[Mr Dash Four <mr.dash.four@googlemail.com>]

> The latter itself exhausts the maximal number of elements in the set, so 
> the error message is normal.
>   
Is this a constraint coming from the "maxelem" value or the hash size? 
Could this be corrected by increasing either of these?

>> The way I look at it, the "old" iptree(map) type sets should be converted to
>> hash:net, not hash:ip to avoid this error.
>>     
>
> That's too late, I can't change the mapping from hash:ip to hash:net.
> (And if the mapping pointed to hash:net, you were surprised then that 
> after adding say 192.68.0.0/24 to the set, you couldn't delete 192.68.0.1 
> from it. :-)
>   
Nope. I am aware that deleting elements in 6.x should be done on the 
whole range when added, not just a single ip address (I am now clear as 
to why that happens and I think it makes sense in the way it is designed).

If you are to provide "backward" compatibility (or compatibility of any 
sort) with iptree(map) sets then you should make sure that at least 
members of that type of set could, at least, register without problem 
within the new set to which iptree(map) is converted. It seems to me 
that is not the case - with 6.5 at least. If it is difficult to maintain 
such compatibility you could do what you have already done with the 
"bindings" in previous versions of ipset - just drop it and ask users to 
switch to the new type. Frankly, it is not that difficult to switch over 
to the new type if one is aware of the implications, so it wouldn't be a 
big shock.