Re: RFH: dropbear initramfs support
On 30/05/15 01:09, Guilhem Moulin wrote:
> - Should [dropbear initramfs support] be included in src:dropbear?
It would probably lead to easier maintenance if it was, if Gerrit is
willing to either sponsor your uploads or give you DM upload rights -
the initial move from "initramfs support is in dropbear.deb" to
"initramfs support is in dropbear-initramfs.deb" would be much easier to
coordinate if it can all go through the NEW queue in one go.
If Gerrit would prefer to split it out of src:dropbear, I suspect it
might be easier to do the binary package split first, let that reach
unstable, then have a new source package take over the new binary
package afterwards?
> - I guess it should be depending on dropbear. However only the
> dropbear binary is interesting, not the configuration files or init
> scripts. Is there a recommended way to proceed in that kind of
> situation? (For instance “NO_START=1” in /etc/default/dropbear is
> probably only useful for people that put dropbear in the initramfs.)
I think separating the binary packages for the actual executable and the
init integration would be best, like the way we have:
* apache2-bin (executable) and apache2 (init script etc.)
* cryptsetup-bin (executable) and cryptsetup (initramfs)
* gnome-session-bin (executable) and gnome-session (gnome-session-bin
configuration for a full GNOME session)
* git (executables) and git-daemon-{run,sysvinit} (git-daemon init
script)
So in this case you might have:
* dropbear-bin (executable, private libraries if any)
* dropbear (init integration goo) Depends: dropbear-bin
* dropbear-initramfs Depends: dropbear-bin, Suggests: dropbear
NO_START in /etc/default/foo is an anti-pattern, IMO - packages aren't
allowed to edit it programmatically, so one of the two use cases (e.g.
in this case dropbear for initramfs only, or dropbear as system daemon)
is always going to need manual reconfiguration. I've been moving away
from it in the (game server) daemon packages I maintain.
S
Reply to: