[pkg-netfilter-team] Bug#911777: Bug#911777: Bug#911777: Bug#911777: iptables: ferm broken by changed path of iptables-restore

[Chris Boot]

On 25/10/2018 10:46, Arturo Borrero Gonzalez wrote:
> On Thu, 25 Oct 2018 at 11:39, Chris Boot <bootc at debian.org> wrote:
>>> So, in this case, perhaps the proper fix is for ferm to don't hardcode
>>> binary paths.
>>
>> Perhaps, but in that case a list of broken packages is going to need to
>> be compiled, bugs filed against them, and (versioned) Breaks added to
>> iptables to make sure that people's systems are not broken by this.
>>
>> It's also going to need a NEWS.Debian entry if there isn't one already
>> (I haven't checked) because people will have written scripts which
>> hard-code the old paths.
>>
> 
> Ok, I agree, fair enough.
> 
> Are we sure that if we introduce some temporal/compatibility symlinks
> for buster, we won't have the same problem again in buster+1?
> i.e, at some point the symlinks in /sbin need to be dropped anyway,
> are we sure a stable release in between is enough time?
> 
> Any volunteers to do this work? The available time I have to work in
> this package right now is very little.

I wasn't saying I favour one way or the other, just that if iptables is
going to make this change then it needs to be done properly. There are
only so many packages that use iptables and they should certainly
Depends/Recommends/Suggests iptables so the work within Debian is
finite. We can't _fix_ users' own scripts, all we can do is warn users
with NEWS.Debian.

I suspect, in time, this will all become moot because usrmerge (on by
default for new installs of buster) effectively makes /sbin and
/usr/sbin the same thing. So perhaps it's not worth the effort and just
leave the iptables scripts in the old locations? I don't personally have
any preference.

Cheers,
Chris

-- 
Chris Boot
bootc at debian.org

GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE EEEE