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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55699363.4070...@debian.org