check: new package

From: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>

Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
---
 package/Config.in        |  1 +
 package/check/Config.in  |  6 ++++++
 package/check/check.hash |  3 +++
 package/check/check.mk   | 21 +++++++++++++++++++++
 4 files changed, 31 insertions(+)
 create mode 100644 package/check/Config.in
 create mode 100644 package/check/check.hash
 create mode 100644 package/check/check.mk

On 07-09-15 15:37, gustavo.zacarias@free-electrons.com wrote:
[snip]
> diff --git a/package/check/check.hash b/package/check/check.hash
> new file mode 100644
> index 0000000..0c3a924
> --- /dev/null
> +++ b/package/check/check.hash
> @@ -0,0 +1,3 @@
> +# From http://sourceforge.net/projects/check/files/check/0.10.0/
> +md5	53c5e5c77d090e103a17f3ed7fd7d8b8	check-0.10.0.tar.gz
> +sha1	35d3a53446aea7b21a770faedb358d0fc7cba76d	check-0.10.0.tar.gz

 Don't we usually add a locally calculated sha256 if only sha1 is available
upstream? (Honest question, I don't remember.)

> diff --git a/package/check/check.mk b/package/check/check.mk
> new file mode 100644
> index 0000000..9b88321
> --- /dev/null
> +++ b/package/check/check.mk
> @@ -0,0 +1,21 @@
> +################################################################################
> +#
> +# check
> +#
> +################################################################################
> +
> +CHECK_VERSION = 0.10.0
> +CHECK_SITE = http://downloads.sourceforge.net/project/check/check/$(CHECK_VERSION)
> +CHECK_INSTALL_STAGING = YES
> +CHECK_DEPENDENCIES = host-pkgconf
> +CHECK_LICENSE = LGPLv2.1+
> +CHECK_LICENSE_FILES = COPYING.LESSER
> +
> +# Having checkmk in the target makes no sense
> +define CHECK_REMOVE_CHECKMK
> +	rm -f $(TARGET_DIR)/usr/bin/checkmk
> +endef
> +CHECK_POST_INSTALL_TARGET_HOOKS += CHECK_REMOVE_CHECKMK
> +
> +$(eval $(autotools-package))
> +$(eval $(host-autotools-package))

 Why do we need a host package?

 Regards,
 Arnout

>

On 07/09/15 11:40, Arnout Vandecappelle wrote:

>> +# From http://sourceforge.net/projects/check/files/check/0.10.0/
>> +md5	53c5e5c77d090e103a17f3ed7fd7d8b8	check-0.10.0.tar.gz
>> +sha1	35d3a53446aea7b21a770faedb358d0fc7cba76d	check-0.10.0.tar.gz
>
>   Don't we usually add a locally calculated sha256 if only sha1 is available
> upstream? (Honest question, I don't remember.)

Hi Arnout.
We normally consider md5 weak (docs), sha1 is so-so but we don't (yet) 
consider it too weak.
For sourceforge they normally provide md5 and sha1, given than an 
intersection of hashes is harder to crack than any single one alone it's 
good to add md5 - as long as there's another better one backing it up as 
well.

>   Why do we need a host package?

Some people may use checkmk which is a host tool, which i remove for the 
target (probably needs full gawk instead of busybox awk, and not very 
useful in the target IMO).
Regards.

On 07-09-15 18:29, Gustavo Zacarias wrote:
> On 07/09/15 11:40, Arnout Vandecappelle wrote:
> 
>>> +# From http://sourceforge.net/projects/check/files/check/0.10.0/
>>> +md5    53c5e5c77d090e103a17f3ed7fd7d8b8    check-0.10.0.tar.gz
>>> +sha1    35d3a53446aea7b21a770faedb358d0fc7cba76d    check-0.10.0.tar.gz
>>
>>   Don't we usually add a locally calculated sha256 if only sha1 is available
>> upstream? (Honest question, I don't remember.)
> 
> Hi Arnout.
> We normally consider md5 weak (docs), sha1 is so-so but we don't (yet) consider
> it too weak.
> For sourceforge they normally provide md5 and sha1, given than an intersection
> of hashes is harder to crack than any single one alone it's good to add md5 - as
> long as there's another better one backing it up as well.

 OK, thanks for the reminder.

> 
>>   Why do we need a host package?
> 
> Some people may use checkmk which is a host tool, which i remove for the target
> (probably needs full gawk instead of busybox awk, and not very useful in the
> target IMO).

 I fully agree on removing checkmk on the target. I can also see that you'd want
it on the host, but the user has no way to select it since there is no
Config.in.host... So the user would have to do an explicit 'make host-check' to
get it. It also won't be tested in the autobuilders.

 So in principle, we only have host packages that are dependencies of other
packages or that have a Config.in.host entry. An exception is when there is
another package that uses it but that has not yet been accepted. Probably the
reverse also exists: a host dependency that is no longer needed but the host
package still exists.

 Thomas recently proposed to violate this principle in the context of the
python-colorama package [1], to which I replied no [2]. But of course that's
still open for discussion.


 Regards,
 Arnout

[1] http://lists.busybox.net/pipermail/buildroot/2015-August/135344.html
[2] http://lists.busybox.net/pipermail/buildroot/2015-September/138893.html

> Regards.
>

On 07/09/15 16:27, Arnout Vandecappelle wrote:

>> Some people may use checkmk which is a host tool, which i remove for the target
>> (probably needs full gawk instead of busybox awk, and not very useful in the
>> target IMO).
>
>   I fully agree on removing checkmk on the target. I can also see that you'd want
> it on the host, but the user has no way to select it since there is no
> Config.in.host... So the user would have to do an explicit 'make host-check' to
> get it. It also won't be tested in the autobuilders.
>
>   So in principle, we only have host packages that are dependencies of other
> packages or that have a Config.in.host entry. An exception is when there is
> another package that uses it but that has not yet been accepted. Probably the
> reverse also exists: a host dependency that is no longer needed but the host
> package still exists.
>
>   Thomas recently proposed to violate this principle in the context of the
> python-colorama package [1], to which I replied no [2]. But of course that's
> still open for discussion.

Hi Arnout.
I don't have any particular use for the host variant, so no plan on 
arguing too much for it.
I'll spin v2 unless someone objects the other way around with a valid 
argument.
Regards.