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?
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.
Cheers,
Arnaud
live well,
vagrant
