一级做人爱c视正版免费

[Patrick Schleizer]

I enjoyed reading:

Linux distributions: Can we do without hooks and triggers?

https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-triggers/

Also enjoyed watching:

GPN19 - Linux package manager sind zu langsam!

https://www.youtube.com/watch?v=TdfEF0zRIL4

Some comments.

I find drop-in .d folders are of supreme usefulness. However, there are
a few non-perfections.

All of these drop-in folders work a bit different.

config drop-in folder example:

/etc/grub.d/

script drop-in folder example:

/etc/default/grub.d/

Process files ending with '~' (created by editor backup files?) or
'dpkg-old'? I think should not.

For the kernel, looks like there is maximum flexibility.

/etc/kernel/header_postinst.d
/etc/kernel/install.d
/etc/kernel/postinst.d
/etc/kernel/postrm.d
/etc/kernel/preinst.d
/etc/kernel/prerm.d

For adduser, there is a nice feature request [1]:
hooks: /etc/adduser/{pre,post}{user,group}{add,del}.d/

But there doesn't seem to be a convention on how such drop-in folders
should be constructed.

One may have opinions on systemd but unrelated to that, I like how
systemd supports drop-ins for virtually anything aiming at maximum
flexibility.

There also seems to be no convention where drop-in folders are located
[/usr/lib|/lib] and /etc; or only in /etc.

It's non-ideal that every application is reinventing config parsing,
drop-ins, hooks, etc.

I've wrote pre.bsh - a bash snippet which gets `source`ed by every
Debian maintainer script I write. It simplifies and abstracts  debugging
and customization. I wish similar functionality was already a default
feature of dpkg.

It would be good of wrappers were stackable. We called this stackable
wrappers and starting explaining the issue as well as discussed
potential solutions.

https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt

My Background: I am a maintainer of Whonix, which is a derivative of Whonix.

cc'd whonix-devel mailing list so all our readers can benefit from you
reply.

Kind regards,
Patrick

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=36019
[2]
https://github.com/Whonix/helper-scripts/blob/master/usr/lib/helper-scripts/pre.bsh
[3]
## The idea of this bash fragment is:
## Say nothing, if everything goes well, but dump everything on error.

## It allows to easily look inside the xtrace of a (Debian maintainer)
script,
## when the DEBDEBUG environment variable is set to 1.

## To use it in other scripts, use something like this:
# if [ -f /usr/lib/helper-scripts/pre.bsh ]; then
#    source /usr/lib/helper-scripts/pre.bsh
# fi

## Error log:
## - implement trap ERR if function errorhandlergeneral does not exist
## - implements a simple error handler if non exists
## - run silent by default
## - write xtrace to temporary log
## - show full xtrace on unexpected non-zero exit code
## - show exit code on unexpected non-zero exit code
## - run syntax check "bash -n" on this script
## - run syntax check "bash -n" on the script that sourced this script

## DEBDEBUG:
##
## enable xtrace (-x) for maintainer script when DEBDEBUG environment
## variable is set to 1.
## For example:
##    sudo DEBDEBUG=1 dpkg -i /path/to/package.deb

## SKIP_SCRIPTS
##
## The SKIP_SCRIPTS environment variable to skip scripts by name
## For example:
##    sudo DEBDEBUG=1 SKIP_SCRIPTS=" security-misc.postinst " dpkg -i
/path/to/package.deb
##
## another example:
##
##    export DEBDEBUG=1
##     export SKIP_SCRIPTS+=" security-misc.postinst "
##     sudo -E dpkg -i /path/to/package.deb

## Colorful output: provides color function

## Shell options: enables errtrace

## Configuration Folders
##
## For example if the name of the package is 'security-misc':
## - /etc/security-misc_maint.d/*.conf
## - /usr/local/etc/security-misc_maint.d/*.conf
##
## For example if the name of the script is 'panic-on-oops':
## - /etc/panic-on-oops_pre.d/*.conf
## - /usr/local/etc/panic-on-oops_pre.d/*.conf