hey y'all! I've been wondering about the role of Guix in system configuration - we, of course, want to support configuration of an entire system, services included, in the system configuration. this is great, however, the extent to which this has done, seems to have informally organized around replicating large amounts of service-specific minute configuration and documentation. take prosody for example, there's almost 600 lines of configuration and documentation, and it doesn't cover vast amounts of configuration, let alone that of the optional modules we package.
where should it end? should every possible configuration option be replicated and documented? it seems infeasable to do that, especially since configuration can change every package update. do we apply our own deprecation policy here, trying to mold old software configurations into new formats? attempting automatic updates of removed configuration options seems fraught, but not doing so would violate our policy. this is, of course, all regarding only non-essential services. I think the current model works great for lower-level, core system services, but when it comes to large projects like nginx and prosody I'm wondering if it's worth it to keep the same informal model for both. I guess, for these, I feel implementing configuration formats rather than specific options would help. it'd simplify service packaging by a lot, allow more code reuse in service definitions, be a lot less susceptible to bitrot with package updates, and would be easier for users to work edge cases into. this isn't like, a Proposal or anything. I just wanted to gather thoughts. - lilah
