While looking at xcrypt migration guide, a fun idea occurred to me. Instead of asking people to update 5 different files, or rather create 5 directories and create a configuration file in every one of them, it would be great to be able just to drop one configuration file that handles it all (and then easily remove it). See: https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation#Migrating_your_system For example, the new file could use ini-like headers: [package.use] sys-libs/glibc -crypt sys-libs/libxcrypt system [package.accept_keywords] >=virtual/libcrypt-2 sys-libs/libxcrypt * [package.unmask] ~virtual/libcrypt-2 [package.use.mask] sys-libs/libxcrypt -system -split-usr [package.use.force] sys-libs/glibc -crypt
I can imagine this would complicate using configuration management tools like Ansible where currently it's easy for each package (separate Ansible roles) to put it's bits and pieces into separate directory/file.
Nobody's talking of removing old configuration files.
(In reply to Tomáš Mózes from comment #1) > I can imagine this would complicate using configuration management tools > like Ansible where currently it's easy for each package (separate Ansible > roles) to put it's bits and pieces into separate directory/file. Typically for these you end up with /path/to/some/config.d/ and your playbooks drop snippets in; then you concat the files together in your ansible playbook to make /path/to/real/config/file. For this bug I'd probably stick closer to the goal. Is the goal to actually have 1 config file? Is the goal to be "Hey I have this upgrade that needs these configuration changes made, how can I easily provide users a pattern to adopt those configuration changes without editing 12 files?" One solution is obviously a file with the configuration in them that is read; but there might be other valid ways to solve this problem.
(In reply to Michał Górny from comment #0) > While looking at xcrypt migration guide, a fun idea occurred to me. Instead > of asking people to update 5 different files, or rather create 5 directories > and create a configuration file in every one of them, it would be great to > be able just to drop one configuration file that handles it all (and then > easily remove it). > > See: > https://wiki.gentoo.org/wiki/Project:Toolchain/ > libcrypt_implementation#Migrating_your_system > > For example, the new file could use ini-like headers: > > [package.use] > sys-libs/glibc -crypt > sys-libs/libxcrypt system > > [package.accept_keywords] > >=virtual/libcrypt-2 > sys-libs/libxcrypt * > > [package.unmask] > ~virtual/libcrypt-2 > > [package.use.mask] > sys-libs/libxcrypt -system -split-usr > > [package.use.force] > sys-libs/glibc -crypt This looks great. For comparison, this is an example of who I've serialized a profile for a minimal nginx container in yaml: packages: - -* - app-shells/bash - sys-apps/baselayout - sys-apps/busybox - www-servers/nginx - =www-servers/nginx-1.16* amd64 package.use: - www-servers/nginx aio nginx_modules_http_dav nginx_modules_http_vhost_traffic_status nginx_modules_stream_map nginx_modules_stream_ssl_preread pcre pcre-jit ssl threads
The Yocto people have a talk at LPC later on how they do it: https://lpc.events/event/18/contributions/1742/. There's streams available.
