On Thu, Jul 5, 2018 at 9:58 AM Mike Looijmans <[email protected]> wrote: > > On 02-07-18 23:13, Richard Purdie wrote: > > On Mon, 2018-07-02 at 18:44 +0100, Alex Kiernan wrote: > >> On Mon, Jul 2, 2018 at 4:06 PM Alex Kiernan <[email protected]> > >> wrote: > >>> > >>> On Mon, Jul 2, 2018 at 3:55 PM Mike Looijmans <mike.looijmans@topic > >>> .nl> wrote: > >>>> > >>>> The sftp-server runs fine using dropbear as SSH backend, I'd > >>>> expect the same > >>>> to be true for the client. Isn't that the case, and will the sftp > >>>> client only > >>>> work with openssh's ssh? > >>>> > >>> > >>> Interesting question... I hadn't realised dropbear didn't have an > >>> sftp > >>> client, but it's clearly a supported combination: > >>> > >>> https://github.com/mkj/dropbear/blob/1656db9e58e7e8188e4ca27ae4892b > >>> 14949c56a5/dbclient.1#L159 > >>> > >>> I'll amend the patch so it depends on ssh not ${PN}-ssh since both > >>> dropbear and openssh provide that. > >>> > >> > >> Hmm... only that gets you this warning: > >> > >> NOTE: Multiple providers are available for runtime ssh (dropbear, > >> openssh) > >> Consider defining a PREFERRED_RPROVIDER entry to match ssh > >> > >> If you've not set it, which feels like a pretty poor upgrade > >> experience; I'm not sure how best to deal with that. > > > > This is not an easy problem to solve. This is why we have the horrible > > VIRTUAL-RUNTIME_* variables, I wish there were a better way... > > > > Basically, bitbake has to have some idea which one to build, letting > > the package manager decide at do_rootfs time isn't really good enough > > for deterministic builds. > > The dropbear/ssh choice seems to be one that is being postponed until image > creation time. There's an IMAGE_FEATURE that appears to make the choice: > IMAGE_FEATURES += "ssh-server-dropbear" > > Since you're building openssh already, there's no need to instruct bitbake to > build more at package compile time. > > Using RDEPENDS and PREFERRED_RPROVIDER or VIRTUAL-RUNTIME will 'break' a lot > of existing setups by installing the wrong ssh client without the engineer > knowing about it. And it will also make it impossible to build two images with > different choices. I can imaging you'd want to have a small size "recover" > image with dropbear and a large size "full" image with openssh in the same > build for the same machine and distro. >
So, is the short answer, that there's no good answer and the status quo is the way to leave it? -- Alex Kiernan -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
