Since it does no harm, I suppose we can address it when we get to rewriting those scripts.

This is best done along with IPsec scripts rewrite.

This would be best done along with firewall scripts rewrite.

@rherold my point bit different
we will take care about DNS little bit later

@dmbaturinI think you misunderstand the concept of this task
this also includes interfaces naming according to their placement,
and we already have it and used before with link files.
Idea is to prevent random assignment of eth0-ethX names
without link files nic port order always different even on devices with the same hardware (we already saw that in various occasions
Idea is to provide a mechanism that will allow defining an order of nic ports, like before was possible with hw-id (which not works anymore)

While I agree that our scripts should be less dependent on interface names, I'm not sure if we should support so called "predictable" interface names, since for the users they are anything but predictable. Definitely not in 1.2.0

Ah, yeah! Used that in my current project.

for example we now investigating possible memory leak in driver
would like to use kmemleak but don´t want to ship it in the default kernel
could be more use cases (for example preconfigured atoptool for automatic stats collection, etc)
really debug image

What's required for Kernel Debug?

Invalid: Modules like SIP conntrack can't be adjusted during runtime (at least I have not found a way). Only module load parameters are supported. :(

kernel debug requires it anyway

Installing a debug image requires a reboot. apt-get installation works online.

don't want to wait for anyone to build this or that package
a preferred way to have it accessible all the time
apart from that, we can add some more things in debug images

Why? Someone can always install any 3rd party debian package via apt after setting up the repositories. This is in no way different to a parallel build and super easy.

That is great, think we need to set up parallel builds than

Thats already possible using the custom package option introduced by @dmbaturin

pdns recursor is from the same people who writes dnsdist.
There are three products wirh diffrent scopes:

pdns recursor is used for forwarder and we not going to include an additional layer

There is no way to signal DOH (DNS over HTTP/S) via dhcp.
DOH and DOT is supported in latest dnsdist packages see https://dnsdist.org/ and https://mailman.powerdns.com/pipermail/dnsdist/2018-August/000466.html.

As far as I can see it is enabled by default in recent frr:

must be reviewed and adjusted to FRR

what is the state of this?
can i close it?

I will bring this up again. We have now in 1.2 all we need.

Have you seen this: https://github.com/reubenhwk/radvd/issues/45 ??

A long time ago (before Oct 2016) I built Roy Marples' dhcpcd and hacked
/opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script to install, configure, and start it up. I've been running with this config for over two years, and it's pretty stable. I'd love for this to be built into VyOS, rather than a local config hack.

@dmbaturin I think you missing purpose, in some environments (e.g. with high-security requirements ) it may be required
if we can we should support it