libsecret: New package

libsecret is a library for storing and retrieving passwords
and other secrets. It communicates with the "Secret Service"
using DBus. gnome-keyring and ksecretservice are both
implementations of a Secret Service.

libsecret replaces libgnome-keyring.

https://wiki.gnome.org/Libsecret

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
---
 package/Config.in              |  1 +
 package/libsecret/Config.in    | 20 ++++++++++++++++++++
 package/libsecret/libsecret.mk | 24 ++++++++++++++++++++++++
 3 files changed, 45 insertions(+)
 create mode 100644 package/libsecret/Config.in
 create mode 100644 package/libsecret/libsecret.mk

On 08/15/2013 07:31 AM, Markos Chandras wrote:

> +config BR2_PACKAGE_LIBSECRET
> +	bool "libsecret"
> +	select BR2_PACKAGE_LIBGLIB2
> +	help
> +	  libsecret is a library for storing and retrieving passwords and other
> +	  secrets. It communicates with the "Secret Service" using DBus.
> +	  gnome-keyring and ksecretservice are both implementations of a Secret
> +	  Service.
> +
> +	  https://wiki.gnome.org/Libsecret

You forgot to inherit LIBGLIB2 depends (WCHAR, THREADS) and add a
comment on why it's unavailable when both aren't available.
Other than that it looks good in principle (untested).
Regards.

On 15 August 2013 11:41, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
> On 08/15/2013 07:31 AM, Markos Chandras wrote:
>
>> +config BR2_PACKAGE_LIBSECRET
>> +     bool "libsecret"
>> +     select BR2_PACKAGE_LIBGLIB2
>> +     help
>> +       libsecret is a library for storing and retrieving passwords and other
>> +       secrets. It communicates with the "Secret Service" using DBus.
>> +       gnome-keyring and ksecretservice are both implementations of a Secret
>> +       Service.
>> +
>> +       https://wiki.gnome.org/Libsecret
>
> You forgot to inherit LIBGLIB2 depends (WCHAR, THREADS) and add a
> comment on why it's unavailable when both aren't available.
> Other than that it looks good in principle (untested).
> Regards.

Hi Gustavo,

Thanks for the review.

Would it be better to replace 'select' with 'depend' to avoid
implicitly enabling these toolchain components?

On 08/15/2013 07:56 AM, Markos Chandras wrote:
> Hi Gustavo,
> 
> Thanks for the review.
> 
> Would it be better to replace 'select' with 'depend' to avoid
> implicitly enabling these toolchain components?

Hi.
For libglib2 and other hard dependencies we usually just depend on the
toolchain components being available and select libglib2 like you did
with a nice comment when the toolchain isn't up to the requirements
saying so...

comment "libsecret requires a toolchain with X and Y support".
depends on !BR2_TOOLCHAIN_HAS_X || !BR2_TOOLCHAIN_HAS_Y
(with the appropiate labels of course!)

Only when there's a real choice (say, two different libglib2
implementations) a depend would be appropiate (xorg is a good example
since there's a choice between full and kdrive/tinyx, and it usually
requires extra configuration - drivers).

Enabling toolchain components is bad, if it did and you add a package as
a later thought after building your basic system you mess things up.

Regards.