On 25/10/2018 10:46, Arturo Borrero Gonzalez wrote: > On Thu, 25 Oct 2018 at 11:39, Chris Boot <bo...@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 bo...@debian.org GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE EEEE
