On 2022-09-23, Arnaud Ferraris wrote: > On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian > <vagr...@debian.org> wrote: >> On 2022-06-04, Jonas Smedegaard wrote: >> > Quoting Arnaud Ferraris (2022-06-04 16:39:03) >> >> Currently u-boot-menu makes use of a single configuration file >> >> one has to edit in order to change the default options. It could >> >> be useful to use config fragments containing only one (or more) >> >> variables, so that different packages could change different >> >> config options (for example, one fragment could modify the >> >> default cmdline, while another one could change the DTB folder). >> > >> > Thanks, that sounds like a useful feature indeed. >> > >> > Seems more sensible for me, however, to implement this using debconf. >> > >> > Otherwise, installation and removal of a package would need to trigger >> > u-boot-menu, and u-boot-menu would need to specially examine such >> > cofigfile snippets to skip snippets belonging to removed but not purged >> > packages. >> >> Well, you could implement configuration files snippets directory outside >> of /etc (e.g. /usr/share/u-boot-menu/snippet.d or something like that), >> which would avoid this problem. u-boot-menu could have a dpkg trigger >> that for when files in this directory change. > > I quite like this approach, thanks for the suggestion! > > Do you think allowing both /etc/u-boot-menu.d (aimed solely at > end-users) and /usr/share/u-boot-menu/conf.d (for other packages and/or > derivatives), with a dpkg trigger only on the latter, would make sense? > Or should we aim only for the /usr/share... approach?
I think it's reasonable, though you'd have to encourage packages to *not* use /etc/u-boot-menu*.d, maybe documenting it in README.Debian... I could see a preference order being /etc/default/u-boot which is overidden by /usr/share/u-boot-menu/conf.d which is overridden by /etc/u-boot-menu.d (or /etc/u-boot-menu/conf.d ?). A fancy implementation might allow /etc to override /usr/share if the filenames match, but that might be more complicated than it's worth. Jonas knows I've fallen into that rabbit hole in packages of the ancient past... :) >> That seems a lot simpler than introducing the complexity of debconf >> generated configuration files... > > Indeed, so far my experiments with debconf for solving this matter have > been sub-optimal at best. > > I'll update my patch in the next few days and submit it asap. Thanks! live well, vagrant
signature.asc
Description: PGP signature
