Bug#1012333: u-boot-menu: add support for using config fragments
On 2022-11-01, Arnaud Ferraris wrote: > Le 23/09/2022 à 19:22, Vagrant Cascadian a écrit : >> On 2022-09-23, Arnaud Ferraris wrote: >>> On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian >>> 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 added some notes about this in both the manpage and a (new) 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 ?). > > Yes, that makes the most sense to me (I also used > /etc/u-boot-menu/conf.d instead of /etc/u-boot-menu.d for consistency). > >> >> 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... :) > > Hmm, I don't think that's worth the hassle as it would add *a lot* of > complexity for very little gain IMHO. > >> >> 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. > > Updated patch attached, as always comments and suggestions are welcome :) Looks good to me! Even uses dpkg-triggers properly. :) Thanks! I'll merge this and take a look at anything else that needs poking at and maybe upload soon... live well, vagrant > From 2949907b16bff2857cff0fb713967d264feb6567 Mon Sep 17 00:00:00 2001 > From: Arnaud Ferraris > Date: Tue, 1 Nov 2022 13:33:22 +0100 > Subject: [PATCH] u-boot-update: allow using config fragments > > In order to allow other packages and/or derivative distros to configure > specific aspects of `u-boot-menu` it can be useful to allow using config > fragments. This patch therefore implements loading config files from > `/usr/share/u-boot-menu/conf.d` (to be used by other packages) and > `/etc/u-boot-menu.d` (to be used by end-users, taking priority over > files under the preceding location), overriding the values loaded from > the default configuration file. > > This commit also adds a dpkg trigger so any modification of files under > `/usr/share/u-boot-menu/conf.d` will result in `u-boot-update` being > automatically run. > --- > debian/README.Debian| 32 > debian/u-boot-menu.postinst | 8 > debian/u-boot-menu.triggers | 1 + > u-boot-update | 9 + > u-boot-update.8 | 16 +++- > 5 files changed, 65 insertions(+), 1 deletion(-) > create mode 100644 debian/README.Debian > create mode 100755 debian/u-boot-menu.postinst > create mode 100644 debian/u-boot-menu.triggers > > diff --git a/debian/README.Debian b/debian/README.Debian > new file mode 100644 > index 000..f502387 > --- /dev/null > +++ b/debian/README.Debian > @@ -0,0 +1,32 @@ > +Configuration files handling > + > + > +Configuration files are read from the following locations, ordered by > priority: > +1. /etc/default/u-boot > +2. /usr/share/u-boot-menu/conf.d/*.conf > +3. /etc/u-boot-menu/conf.d/*.conf > + > +Each configuration file can contain one or more
Bug#1012333: u-boot-menu: add support for using config fragments
Hi Jonas, Vagrant, On Tue, 1 Nov 2022 14:18:11 +0100 Arnaud Ferraris wrote: > > > > 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 added some notes about this in both the manpage and a (new) 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 ?). > > Yes, that makes the most sense to me (I also used > /etc/u-boot-menu/conf.d instead of /etc/u-boot-menu.d for consistency). > > > > > 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... :) > > Hmm, I don't think that's worth the hassle as it would add *a lot* of > complexity for very little gain IMHO. > Gentle ping :)
Bug#1012333: u-boot-menu: add support for using config fragments
Hi, Le 23/09/2022 à 19:22, Vagrant Cascadian a écrit : On 2022-09-23, Arnaud Ferraris wrote: On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian 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 added some notes about this in both the manpage and a (new) 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 ?). Yes, that makes the most sense to me (I also used /etc/u-boot-menu/conf.d instead of /etc/u-boot-menu.d for consistency). 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... :) Hmm, I don't think that's worth the hassle as it would add *a lot* of complexity for very little gain IMHO. 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. Updated patch attached, as always comments and suggestions are welcome :) Cheers, Arnaud Thanks! live well, vagrant From 2949907b16bff2857cff0fb713967d264feb6567 Mon Sep 17 00:00:00 2001 From: Arnaud Ferraris Date: Tue, 1 Nov 2022 13:33:22 +0100 Subject: [PATCH] u-boot-update: allow using config fragments In order to allow other packages and/or derivative distros to configure specific aspects of `u-boot-menu` it can be useful to allow using config fragments. This patch therefore implements loading config files from `/usr/share/u-boot-menu/conf.d` (to be used by other packages) and `/etc/u-boot-menu.d` (to be used by end-users, taking priority over files under the preceding location), overriding the values loaded from the default configuration file. This commit also adds a dpkg trigger so any modification of files under `/usr/share/u-boot-menu/conf.d` will result in `u-boot-update` being automatically run. --- debian/README.Debian| 32 debian/u-boot-menu.postinst | 8 debian/u-boot-menu.triggers | 1 + u-boot-update | 9 + u-boot-update.8 | 16 +++- 5 files changed, 65 insertions(+), 1 deletion(-) create mode 100644 debian/README.Debian create mode 100755 debian/u-boot-menu.postinst create mode 100644 debian/u-boot-menu.triggers diff --git a/debian/README.Debian b/debian/README.Debian new file mode 100644 index 000..f502387 --- /dev/null +++ b/debian/README.Debian @@ -0,0 +1,32 @@ +Configuration files handling + + +Configuration files are read from the following locations, ordered by priority: +1. /etc/default/u-boot +2. /usr/share/u-boot-menu/conf.d/*.conf +3. /etc/u-boot-menu/conf.d/*.conf + +Each configuration file can contain one or more environment variable and is +sourced by u-boot-update. See u-boot-update(8) for more information about +allowed variables. + +Variables values can be overriden by highest-priority configuration files. For +example, if /etc/default/u-boot contains `U_BOOT_DEFAULT=l0` and there is a +file named /usr/share/u-boot-menu/conf.d/new-default.conf containing +`U_BOOT_DEFAULT=l0r`, then the menu entry labelled `l0r` will be set as the +default entry. Moreover, if there is a file named, for
Bug#1012333: u-boot-menu: add support for using config fragments
Hi Jonas, Le 24/09/2022 à 00:22, Jonas Smedegaard a écrit : Quoting Arnaud Ferraris (2022-09-23 14:51:40) On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian wrote: On 2022-06-04, Jonas Smedegaard wrote: Seems more sensible for me, however, to implement this using debconf. [ thoughts on non-debconf mechanism snipped ] 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. Can you elaborate on your bad experiences with debconf? By using debconf (and unless I'm doing things wrong, which is definitely possible), this requires having one question/template for each variable, and potentially as many preseeds. I find this a bit cumbersome, especially with the use of config fragments being a widespread practice, making it easier for both packages and users to add/override config parameters IMHO. The case where 2 packages want to change the same variable is also more difficult to handle, and it also prevents taking advantage of the shell script-based config sourcing (where one could just expand an existing variable instead of rewriting all of it). Finally, having a single debconf-generated config file makes changes in the default configuration tricky if both the third-party packages and the user make such changes. Lastly, it makes me a bit uneasy as the Debian Policy[1] and Developer's Reference[2] recommend that debconf be used only when necessary (at least in my understanding). Regards, Arnaud [1] https://www.debian.org/doc/debian-policy/ch-binary.html#prompting-in-maintainer-scripts [2] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#best-practices-for-maintainer-scripts - Jonas
Bug#1012333: u-boot-menu: add support for using config fragments
Quoting Arnaud Ferraris (2022-09-23 14:51:40) > On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian > wrote: > > On 2022-06-04, Jonas Smedegaard wrote: > > > Seems more sensible for me, however, to implement this using debconf. [ thoughts on non-debconf mechanism snipped ] > > 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. Can you elaborate on your bad experiences with debconf? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1012333: u-boot-menu: add support for using config fragments
On 2022-09-23, Arnaud Ferraris wrote: > On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian > 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
Bug#1012333: u-boot-menu: add support for using config fragments
On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian 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
Bug#1012333: u-boot-menu: add support for using config fragments
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. That seems a lot simpler than introducing the complexity of debconf generated configuration files... live well, vagrant signature.asc Description: PGP signature
Bug#1012333: u-boot-menu: add support for using config fragments
Le 04/06/2022 à 17:39, Jonas Smedegaard a écrit : 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. How does that sound to you? Do you imagine some scenarios where addon packages would be needed and debconf would be unusable, then please elaborate on that... I'm honestly not really familiar with debconf (yet), especially when it comes to inter-packages interactions, but this sounds sensible indeed. I'll experiment with it a bit and get back to you once I've found out what works (and what doesn't if any). Please note this has been previously submitted as a merge request on salsa Thanks for reporting here as a bugreport: Debian uses debbugs for tracking issues. Salsa confusingly ofer isue tracking as well and even has that feature enabled by default. Sorry for the confusion, I will now disable the issue tracker for this project to not be misleading in the future. Understood, I'll make sure to use the BTS in the future. Thanks, Arnaud - Jonas
Bug#1012333: u-boot-menu: add support for using config fragments
Quoting Jonas Smedegaard (2022-06-04 17:39:23) > Quoting Arnaud Ferraris (2022-06-04 16:39:03) > > Please note this has been previously submitted as a merge request > > on salsa > > Thanks for reporting here as a bugreport: Debian uses debbugs for > tracking issues. Salsa confusingly ofer isue tracking as well and even > has that feature enabled by default. Sorry for the confusion, I will > now disable the issue tracker for this project to not be misleading in > the future. I won't disable the confusing double issue tracker after all: Apparently another maintainer (Vagrant) has embrased the double tracker, so I will leave it up to him to ensure transparency in Debian regarding bugtracking. Personally I will continue to *not* use the confusing double tracker. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1012333: u-boot-menu: add support for using config fragments
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. How does that sound to you? Do you imagine some scenarios where addon packages would be needed and debconf would be unusable, then please elaborate on that... > Please note this has been previously submitted as a merge request > on salsa Thanks for reporting here as a bugreport: Debian uses debbugs for tracking issues. Salsa confusingly ofer isue tracking as well and even has that feature enabled by default. Sorry for the confusion, I will now disable the issue tracker for this project to not be misleading in the future. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1012333: u-boot-menu: add support for using config fragments
Source: u-boot-menu
Version: 4.0.4
Severity: wishlist
Tags: patch
X-Debbugs-Cc: arnaud.ferra...@gmail.com
Dear Maintainer,
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).
The attached patch implements such a feature by sourcing any
*.conf file present under the /etc/u-boot-menu.d folder.
Please note this has been previously submitted as a merge request
on salsa[1], which I'm doubling with a BTS entry in case you
prefer handling such requests that way.
[1] https://salsa.debian.org/debian/u-boot-menu/-/merge_requests/5
Thanks,
Arnaud
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.0-1-rt-amd64 (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 093b48b42afe03e1e0013d66ef2752ed9460bca8 Mon Sep 17 00:00:00 2001
From: Arnaud Ferraris
Date: Tue, 14 Sep 2021 20:36:04 +0200
Subject: [PATCH] u-boot-update: allow using config fragments
In order to allow other packages and/or derivative distros to configure
specific aspects of `u-boot-menu` it can be useful to allow using config
fragments. This patch therefore implements loading config files from
`/etc/u-boot-menu.d`, overriding the values loaded from the default
configuration file.
---
u-boot-update | 9 +
u-boot-update.8 | 5 -
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/u-boot-update b/u-boot-update
index da92918..d4af7c3 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -49,6 +49,15 @@ then
. /etc/default/u-boot
fi
+# Reading config file fragments if they exist
+for file in /etc/u-boot-menu.d/*.conf
+do
+ if [ -e "${file}" ]
+ then
+ . "${file}"
+ fi
+done
+
# Reading the os-release file
if [ -e /etc/os-release ]
then
diff --git a/u-boot-update.8 b/u-boot-update.8
index 38f533b..becd57a 100644
--- a/u-boot-update.8
+++ b/u-boot-update.8
@@ -9,7 +9,9 @@ u\-boot\-update \- program to generate u\-boot menu files
.SH DESCRIPTION
u\-boot\-update is a tool used to generate the menu files
used by the U\-BOOT bootloader.
-Options can be configured in /etc/default/u\-boot.
+Options can be configured in /etc/default/u\-boot or by
+adding configuration fragment files to /etc/u\-boot\-menu.d/
+(those take precedence over /etc/default/u\-boot).
.PP
@@ -107,6 +109,7 @@ Default is 'device-tree.dtb'.
.SH FILES
/etc/default/u-boot
+/etc/u-boot-menu.d/
.SH HOMEPAGE
More information about U\-BOOT
--
2.35.1
