On 06/29/2011 01:56 AM, Koen Kooi wrote:
Op 29 jun 2011, om 10:50 heeft Anders Darander het volgende
geschreven:
On Wed, Jun 29, 2011 at 10:24, Koen
Kooi<[email protected]> wrote:
Op 29 jun 2011, om 00:41 heeft Khem Raj het volgende geschreven:
If they are independent then may be the openssh recipe should
be divided into openssh-ssh and openssh-rest so one can use
openssh provided daemon or dropbear provided as they wish
Dividing the openssl recipe would gain us little and the gains
would be only for the power companies since you'd have to build
openssh twice to get both sftp and ssh. The decrease in build
time for only sftp is neglible.
Hm, speaking against what I've often been advocating (reducing
build time by factoring out dependenies etc)...
I think the simplest and most straightforward solution is to just
split the packaging into openssh-ssh and openssh-sftp, where
openssh-sftp packages just what is needed for handling the
sftp-server in cooperation with dropbear. It could possibly also
include the sftp-client if desired/needed.
That's already the case now. The problem is the PROVIDES overlap
since the Poky people decided a distro could only have one true ssh
implementation instead of choosing it per image. So if your distro
doesn't set the PREFERRED_PROVIDER_sshd you get those nagging
messages during parsing that scare users and make consultants rich.
OE .dev isn't a lot better with the misguided DISTRO_SSH_DAEMON, but
at least it doesn't show those nag messages.
It's worth noting that one of the things I got into master just after
Yocto 1.0 shipped was a refactoring of how ssh servers were specified.
It no longer is a distro choice - we have task-core-ssh-openssh and
task-core-ssh-dropbear that you add to IMAGE_FEATURES for your desired
image.
Which makes me wonder what the consequences would be to simply remove
the PROVIDES from the dropbear and openssh recipes?
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
