From: Scott Garman <scott.a.garman@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: Conflicting providers for ssh/sshd (dropbear and openssh)
Date: Wed, 29 Jun 2011 10:03:29 -0700 [thread overview]
Message-ID: <4E0B5AE1.6030006@intel.com> (raw)
In-Reply-To: <7848FD2A-860F-48C3-BE1D-739C6D9AB0A8@dominion.thruhere.net>
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<koen@dominion.thruhere.net> 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
next prev parent reply other threads:[~2011-06-29 17:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 22:41 Conflicting providers for ssh/sshd (dropbear and openssh) Khem Raj
2011-06-28 22:51 ` Scott Garman
2011-06-28 23:50 ` Khem Raj
2011-06-28 23:53 ` Graeme Gregory
2011-06-29 1:07 ` Khem Raj
2011-06-29 7:42 ` Anders Darander
2011-06-29 0:34 ` Scott Garman
2011-06-29 8:24 ` Koen Kooi
2011-06-29 8:50 ` Anders Darander
2011-06-29 8:56 ` Koen Kooi
2011-06-29 9:08 ` Phil Blundell
2011-06-29 9:42 ` Richard Purdie
2011-06-29 9:51 ` Phil Blundell
2011-06-29 10:23 ` Richard Purdie
2011-06-29 9:13 ` Anders Darander
2011-06-29 17:03 ` Scott Garman [this message]
2011-07-03 12:26 ` Philip Balister
2011-07-03 15:41 ` Graeme Gregory
2011-06-29 8:56 ` Graeme Gregory
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E0B5AE1.6030006@intel.com \
--to=scott.a.garman@intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.