Ok, sounds reasonable.

(a bit late, sorry)

@Kristian Amlie I heard from you in SU, but let me say it loud and clear: the .d directory is a great idea!

What's the best way of distributing it?

1. Should it be part of the mender-configure.deb package? This would conflict with having your own script at /usr/lib/mender-configure/apply-device-config, but OTOH, all you need to do is to move it to /usr/lib/mender-configure/apply-device-config.d/myscript and you'd get the same behavior.
2. Should it be it's own package? Something we recommend installing but that you don't have to?
3. Something else?

Following Debian principles, the directory should be part of mender-configure deb package, but the scripts should go to a different package (mender-configure-apply?). The point is that if the scripts are distributed in the main package, and the user is expected to remove or edit some of them, then the package will not upgrade automatically on next apt-get update, which is a bad practice.

However, I suggest we drop making this second package for now, and just install the scripts manually in our tutorials. I think we need a task force to really plan our Debian packages (goes hand with hand with clearing our technical dept in https://northerntech.atlassian.net/browse/MEN-4248#icft=MEN-4248).

Yes, I think you are right, it's better to simply omit the apply-device-config script altogether, and fully commit to a .d based structure. Will do that!

Also a nice idea with a Mender Hub category. These would probably be a bit less reusable than Update Modules, so perhaps not spend too much effort on defining the structure, etc. now. Do we need some kind of follow-up task for this (can also be done quite late in the release)?

Yes, I created one here. The criteria are somewhat vague, it can be figured out on the go I think, and as you say, it might not need to be quite as rigid as the Update Module pages.

It was how I envisioned this to develop over time as well (more modular, maybe even a script being responsible for a particular service only - and called if relevant for that device). So it's good you just did it.

I also support option 1. Isn't this quite standard Unix behavior (and should thus be quite intuitive)? The only thing to consider is if we then need apply-device-config at all, or should we move that logic (executing everything in apply-device-config.d) to the Update Module itself? It could be a bit confusing if some people start editing apply-device-config, while others drop scripts into apply-device-config.d - at least we should standardize on the latter in docs.

Also a nice idea with a Mender Hub category. These would probably be a bit less reusable than Update Modules, so perhaps not spend too much effort on defining the structure, etc. now. Do we need some kind of follow-up task for this (can also be done quite late in the release)?

@eystein.maloy.stenberg, @Lluis Campos: While working on this, I concluded that altering timezone is a real life use case and therefore it makes sense to put this into something reusable, which can be used also outside a demo. But this clashes with RaspberryPi led manipulation, which is very "demoey". How to split that up?

I then realized that with very simple measures we can make the apply-device-config script far more pluggable and thereby opening for having "device config module page" on Mender Hub where people can mix and match scripts that configure various parts of the system. I've just implemented an apply-device-config script which scans /usr/lib/mender-configure/apply-device-config.d and executes all the scripts there with the same parameters as it's given. IOW you can just drop in scripts and they will modify "their part" of the JSON.

I would be surprised if anyone objects to this design; and I need it in this task, so I've already implemented it. The question I want to ask though, is: What's the best way of distributing it?

1. Should it be part of the mender-configure.deb package? This would conflict with having your own script at /usr/lib/mender-configure/apply-device-config, but OTOH, all you need to do is to move it to /usr/lib/mender-configure/apply-device-config.d/myscript and you'd get the same behavior.

2. Should it be it's own package? Something we recommend installing but that you don't have to?

3. Something else?

I'm leaning rather heavily towards the first option, but I'd like your opinions.