<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 25, 2019 at 11:10 AM Patrick Schleizer <<a href="mailto:adrelanos@riseup.net">adrelanos@riseup.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I enjoyed reading:<br>
<br>
Linux distributions: Can we do without hooks and triggers?<br>
<br>
<a href="https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-triggers/" rel="noreferrer" target="_blank">https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-triggers/</a><br>
<br>
Also enjoyed watching:<br>
<br>
GPN19 - Linux package manager sind zu langsam!<br>
<br>
<a href="https://www.youtube.com/watch?v=TdfEF0zRIL4" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=TdfEF0zRIL4</a></blockquote><div><br></div><div>Thanks! For those unfamiliar with this work, I think <a href="https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/">https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/</a> might be the best starting point :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Some comments.<br>
<br>
I find drop-in .d folders are of supreme usefulness. However, there are<br>
a few non-perfections.<br>
<br>
All of these drop-in folders work a bit different.<br>
<br>
config drop-in folder example:<br>
<br>
/etc/grub.d/<br>
<br>
script drop-in folder example:<br>
<br>
/etc/default/grub.d/<br>
<br>
Process files ending with '~' (created by editor backup files?) or<br>
'dpkg-old'? I think should not.<br></blockquote><div><br></div><div>In Debian, typically a specific suffix is required for the file to be considered, which excludes all sorts of temporary replacements and backup files. E.g., files in /etc/apt/sources.list.d/ require ending in .list.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For the kernel, looks like there is maximum flexibility.<br>
<br>
/etc/kernel/header_postinst.d<br>
/etc/kernel/install.d<br>
/etc/kernel/postinst.d<br>
/etc/kernel/postrm.d<br>
/etc/kernel/preinst.d<br>
/etc/kernel/prerm.d<br>
<br>
For adduser, there is a nice feature request [1]:<br>
hooks: /etc/adduser/{pre,post}{user,group}{add,del}.d/<br>
<br>
But there doesn't seem to be a convention on how such drop-in folders<br>
should be constructed.<br></blockquote><div><br></div><div>Indeed, I’m not aware of any codified best practices regarding .d directories either. It would be great to write something down! I’d be happy to review/contribute.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
One may have opinions on systemd but unrelated to that, I like how<br>
systemd supports drop-ins for virtually anything aiming at maximum<br>
flexibility.<br>
<br>
There also seems to be no convention where drop-in folders are located<br>
[/usr/lib|/lib] and /etc; or only in /etc.<br></blockquote><div><br></div><div>I’d argue that systemd’s locations in that regard form a de-facto standard.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It's non-ideal that every application is reinventing config parsing,<br>
drop-ins, hooks, etc.<br></blockquote><div><br></div><div>Indeed, but that’s a much bigger battle ;). IMO, any guidelines regarding .d parsing should be generic enough that they can easily be implemented in any application. The first step is to unify behavior, and unifying implementations can come later.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I've wrote pre.bsh - a bash snippet which gets `source`ed by every<br>
Debian maintainer script I write. It simplifies and abstracts  debugging<br>
and customization. I wish similar functionality was already a default<br>
feature of dpkg.<br>
<br>
It would be good of wrappers were stackable. We called this stackable<br>
wrappers and starting explaining the issue as well as discussed<br>
potential solutions.<br>
<br>
<a href="https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt" rel="noreferrer" target="_blank">https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt</a><br>
<br>
My Background: I am a maintainer of Whonix, which is a derivative of Whonix.<br>
<br>
cc'd whonix-devel mailing list so all our readers can benefit from you<br>
reply.<br>
<br>
Kind regards,<br>
Patrick<br>
<br>
[1] <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=36019" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=36019</a><br>
[2]<br>
<a href="https://github.com/Whonix/helper-scripts/blob/master/usr/lib/helper-scripts/pre.bsh" rel="noreferrer" target="_blank">https://github.com/Whonix/helper-scripts/blob/master/usr/lib/helper-scripts/pre.bsh</a><br>
[3]<br>
## The idea of this bash fragment is:<br>
## Say nothing, if everything goes well, but dump everything on error.<br>
<br>
## It allows to easily look inside the xtrace of a (Debian maintainer)<br>
script,<br>
## when the DEBDEBUG environment variable is set to 1.<br>
<br>
## To use it in other scripts, use something like this:<br>
# if [ -f /usr/lib/helper-scripts/pre.bsh ]; then<br>
#    source /usr/lib/helper-scripts/pre.bsh<br>
# fi<br>
<br>
## Error log:<br>
## - implement trap ERR if function errorhandlergeneral does not exist<br>
## - implements a simple error handler if non exists<br>
## - run silent by default<br>
## - write xtrace to temporary log<br>
## - show full xtrace on unexpected non-zero exit code<br>
## - show exit code on unexpected non-zero exit code<br>
## - run syntax check "bash -n" on this script<br>
## - run syntax check "bash -n" on the script that sourced this script<br>
<br>
## DEBDEBUG:<br>
##<br>
## enable xtrace (-x) for maintainer script when DEBDEBUG environment<br>
## variable is set to 1.<br>
## For example:<br>
##    sudo DEBDEBUG=1 dpkg -i /path/to/package.deb<br>
<br>
## SKIP_SCRIPTS<br>
##<br>
## The SKIP_SCRIPTS environment variable to skip scripts by name<br>
## For example:<br>
##    sudo DEBDEBUG=1 SKIP_SCRIPTS=" security-misc.postinst " dpkg -i<br>
/path/to/package.deb<br>
##<br>
## another example:<br>
##<br>
##    export DEBDEBUG=1<br>
##     export SKIP_SCRIPTS+=" security-misc.postinst "<br>
##     sudo -E dpkg -i /path/to/package.deb<br>
<br>
## Colorful output: provides color function<br>
<br>
## Shell options: enables errtrace<br>
<br>
## Configuration Folders<br>
##<br>
## For example if the name of the package is 'security-misc':<br>
## - /etc/security-misc_maint.d/*.conf<br>
## - /usr/local/etc/security-misc_maint.d/*.conf<br>
##<br>
## For example if the name of the script is 'panic-on-oops':<br>
## - /etc/panic-on-oops_pre.d/*.conf<br>
## - /usr/local/etc/panic-on-oops_pre.d/*.conf<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<div>Michael</div></div></div></div>