Bug#944748: [pkg-netfilter-team] Bug#944748: nftables: no init script
On Fri, 20 Oct 2023 11:35:38 +0200 Magnus Holmgren wrote: Reminder that this bug isn't about building support for saving the currently loaded ruleset to a file and reloading it after reboot, only about adding a minimal init script that does the same job as the existing systemd unit. There wont be any sysvinit integration in this package. Sorry. rules and then saving the changes, but to facilitate integration of other packages with nftables, I think coming up with some scheme where those packages can drop configuration snippets in /etc/nftables.d, or perhaps /etc/ This should be done by other components such as firewalld. No such functions will be added to the nftables package. The nftables package will just deploy the `nft` binary plus a few skeleton ruleset and other example. I'm already regretting the systemd integration at all.
Bug#944748: [pkg-netfilter-team] Bug#944748: nftables: no init script
On Fri, 15 Nov 2019 14:29:44 + (UTC) Thorsten Glaser wrote: > Arturo Borrero Gonzalez dixit: > > >I'm sorry, but I don't plan to work on any kind of sysvinit support for nftables. > […] > >Anyway, I'm closing the bug report as wontfix. > > Feel free to have it as wontfix, but it’s still a serious > current Policy violation and thus RC. Not fixing it will > make your package unsuitable for a stable release. Reminder that this bug isn't about building support for saving the currently loaded ruleset to a file and reloading it after reboot, only about adding a minimal init script that does the same job as the existing systemd unit. I actually like how you can actually write your rules in a fairly readable, structured format, making it easier to make changes by editing the configuration and reloading as opposed to executing commands to add or delete rules and then saving the changes, but to facilitate integration of other packages with nftables, I think coming up with some scheme where those packages can drop configuration snippets in /etc/nftables.d, or perhaps /etc/ nftables/input.d etc., could be helpful. (This would work because the include statement can be used in various places, not just at the top level, and an include statement with wildcard symbols that matches no files is no error.) This is again a whole separate issue, though. -- Magnus Holmgren Debian Developer
Bug#944748: [pkg-netfilter-team] Bug#944748: nftables: no init script
reopen 944748 severity 944748 serious thanks Arturo Borrero Gonzalez dixit: >I'm sorry, but I don't plan to work on any kind of sysvinit support for >nftables. […] >Anyway, I'm closing the bug report as wontfix. Feel free to have it as wontfix, but it’s still a serious current Policy violation and thus RC. Not fixing it will make your package unsuitable for a stable release. But, trying to be constructive here, would you be amenable to merging sysvinit support maintained by me? Thanks, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#944748: [pkg-netfilter-team] Bug#944748: nftables: no init script
Control: tags -1 wontfix Control: severity -1 normal On 11/14/19 7:00 PM, Thorsten Glaser wrote: > [..] > > However, nftables appears to ship a systemd unit, which is a > clear violation of Policy §9.11: > “However, any package integrating with other init systems > must also be backwards-compatible with sysvinit by providing a SysV- > style init script with the same name as and equivalent functionality > to any init-specific job, as this is the only start-up configuration > method guaranteed to be supported by all init implementations.” > > I checked latest version of Policy, and this is still there. > So please make a stable update adding an init script. > Hey! Thanks for getting in touch. I'm sorry, but I don't plan to work on any kind of sysvinit support for nftables. That Debian Policy bit is known to be flawed and a work in progress, to better reflect the reality of now-a-days Debian systems [0]. If you are aware of that, I wonder what is the purpose of this bug report. If you weren't aware of that, I'm glad now you are :-) Anyway, I'm closing the bug report as wontfix. regards. [0] https://lists.debian.org/debian-devel-announce/2019/10/msg2.html
