Patchwork [08/11] opkg: Add --no-install-recommends option.

login
register
mail settings
Submitter Mark Hatle
Date Aug. 14, 2013, 8:30 p.m.
Message ID <1376512209-11622-9-git-send-email-mark.hatle@windriver.com>
Download mbox | patch
Permalink /patch/55639/
State New
Headers show

Comments

Mark Hatle - Aug. 14, 2013, 8:30 p.m.
The new --no-install-recommends option is similar to the behavior of
apt-get's --no-install-recommedns.  Only required packages will be
installed.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 .../opkg/opkg/no-install-recommends.patch          | 78 ++++++++++++++++++++++
 meta/recipes-devtools/opkg/opkg_svn.bb             |  4 +-
 2 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
Saul Wold - Aug. 19, 2013, 6:08 p.m.
On 08/14/2013 01:30 PM, Mark Hatle wrote:
> The new --no-install-recommends option is similar to the behavior of
> apt-get's --no-install-recommedns.  Only required packages will be
> installed.
>
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> ---
>   .../opkg/opkg/no-install-recommends.patch          | 78 ++++++++++++++++++++++
>   meta/recipes-devtools/opkg/opkg_svn.bb             |  4 +-
>   2 files changed, 81 insertions(+), 1 deletion(-)
>   create mode 100644 meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
>
> diff --git a/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch b/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
> new file mode 100644
> index 0000000..f71b027
> --- /dev/null
> +++ b/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
> @@ -0,0 +1,78 @@
> +Add the ability to not install ANY recommended packages.
> +
> +Upstream-status: Pending

Upstream-Status: here, in add-exclude.patch and 
smart-config-ignore-all-recommends.patch

Thanks
	Sau!

> +
> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> +
> +Index: trunk/libopkg/opkg_conf.h
> +===================================================================
> +--- trunk.orig/libopkg/opkg_conf.h
> ++++ trunk/libopkg/opkg_conf.h
> +@@ -80,6 +80,7 @@ struct opkg_conf
> +      int prefer_arch_to_version;
> +      int check_signature;
> +      int nodeps; /* do not follow dependencies */
> ++     int noinstall_recommends;
> +      char *offline_root;
> +      char *overlay_root;
> +      int query_all;
> +Index: trunk/libopkg/pkg_depends.c
> +===================================================================
> +--- trunk.orig/libopkg/pkg_depends.c
> ++++ trunk/libopkg/pkg_depends.c
> +@@ -19,6 +19,7 @@
> + #include <ctype.h>
> +
> + #include "pkg.h"
> ++#include "opkg_conf.h"
> + #include "opkg_utils.h"
> + #include "pkg_hash.h"
> + #include "opkg_message.h"
> +@@ -204,7 +205,7 @@ pkg_hash_fetch_unsatisfied_dependencies(
> + 		    /* user request overrides package recommendation */
> + 		    if (satisfying_pkg != NULL
> + 			&& (compound_depend->type == RECOMMEND || compound_depend->type == SUGGEST)
> +-			&& (satisfying_pkg->state_want == SW_DEINSTALL || satisfying_pkg->state_want == SW_PURGE)) {
> ++			&& (satisfying_pkg->state_want == SW_DEINSTALL || satisfying_pkg->state_want == SW_PURGE || conf->noinstall_recommends)) {
> + 			 opkg_msg(NOTICE, "%s: ignoring recommendation for "
> + 					"%s at user request\n",
> + 					pkg->name, satisfying_pkg->name);
> +Index: trunk/src/opkg-cl.c
> +===================================================================
> +--- trunk.orig/src/opkg-cl.c
> ++++ trunk/src/opkg-cl.c
> +@@ -50,6 +50,7 @@ enum {
> + 	ARGS_OPT_NODEPS,
> + 	ARGS_OPT_AUTOREMOVE,
> + 	ARGS_OPT_CACHE,
> ++	ARGS_OPT_NOINSTALL_RECOMMENDS,
> + };
> +
> + static struct option long_options[] = {
> +@@ -89,6 +90,7 @@ static struct option long_options[] = {
> + 	{"noaction", 0, 0, ARGS_OPT_NOACTION},
> + 	{"download-only", 0, 0, ARGS_OPT_DOWNLOAD_ONLY},
> + 	{"nodeps", 0, 0, ARGS_OPT_NODEPS},
> ++	{"no-install-recommends", 0, 0, ARGS_OPT_NOINSTALL_RECOMMENDS},
> + 	{"offline", 1, 0, 'o'},
> + 	{"offline-root", 1, 0, 'o'},
> + 	{"add-arch", 1, 0, ARGS_OPT_ADD_ARCH},
> +@@ -199,6 +201,9 @@ args_parse(int argc, char *argv[])
> + 		case ARGS_OPT_NOACTION:
> + 			conf->noaction = 1;
> + 			break;
> ++		case ARGS_OPT_NOINSTALL_RECOMMENDS:
> ++			conf->noinstall_recommends = 1;
> ++			break;
> +         case ARGS_OPT_DOWNLOAD_ONLY:
> + 			conf->download_only = 1;
> + 			break;
> +@@ -293,6 +298,8 @@ usage()
> + 	printf("\t--noaction		No action -- test only\n");
> + 	printf("\t--download-only	No action -- download only\n");
> + 	printf("\t--nodeps		Do not follow dependencies\n");
> ++	printf("\t--no-install-recommends\n");
> ++	printf("\t                      Do not install any recommended packages\n");
> + 	printf("\t--force-removal-of-dependent-packages\n");
> + 	printf("\t			Remove package and all dependencies\n");
> + 	printf("\t--autoremove		Remove packages that were installed\n");
> diff --git a/meta/recipes-devtools/opkg/opkg_svn.bb b/meta/recipes-devtools/opkg/opkg_svn.bb
> index 032578d..dbfca0f 100644
> --- a/meta/recipes-devtools/opkg/opkg_svn.bb
> +++ b/meta/recipes-devtools/opkg/opkg_svn.bb
> @@ -1,6 +1,8 @@
>   require opkg.inc
>
> -SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http"
> +SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
> +           file://no-install-recommends.patch \
> +"
>
>   S = "${WORKDIR}/trunk"
>
>
Mark Hatle - Aug. 19, 2013, 6:32 p.m.
On 8/19/13 1:08 PM, Saul Wold wrote:
> On 08/14/2013 01:30 PM, Mark Hatle wrote:
>> The new --no-install-recommends option is similar to the behavior of
>> apt-get's --no-install-recommedns.  Only required packages will be
>> installed.
>>
>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>> ---
>>    .../opkg/opkg/no-install-recommends.patch          | 78 ++++++++++++++++++++++
>>    meta/recipes-devtools/opkg/opkg_svn.bb             |  4 +-
>>    2 files changed, 81 insertions(+), 1 deletion(-)
>>    create mode 100644 meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
>>
>> diff --git a/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch b/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
>> new file mode 100644
>> index 0000000..f71b027
>> --- /dev/null
>> +++ b/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
>> @@ -0,0 +1,78 @@
>> +Add the ability to not install ANY recommended packages.
>> +
>> +Upstream-status: Pending
>
> Upstream-Status: here, in add-exclude.patch and
> smart-config-ignore-all-recommends.patch

I've updated these three and pushed to poky-contrib mhatle/oe-core-remove 
(note, there are a few patches there that are NOT part of this set.  So be sure 
to take only the top 11.)

--Mark

> Thanks
> 	Sau!
>
>> +
>> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>> +
>> +Index: trunk/libopkg/opkg_conf.h
>> +===================================================================
>> +--- trunk.orig/libopkg/opkg_conf.h
>> ++++ trunk/libopkg/opkg_conf.h
>> +@@ -80,6 +80,7 @@ struct opkg_conf
>> +      int prefer_arch_to_version;
>> +      int check_signature;
>> +      int nodeps; /* do not follow dependencies */
>> ++     int noinstall_recommends;
>> +      char *offline_root;
>> +      char *overlay_root;
>> +      int query_all;
>> +Index: trunk/libopkg/pkg_depends.c
>> +===================================================================
>> +--- trunk.orig/libopkg/pkg_depends.c
>> ++++ trunk/libopkg/pkg_depends.c
>> +@@ -19,6 +19,7 @@
>> + #include <ctype.h>
>> +
>> + #include "pkg.h"
>> ++#include "opkg_conf.h"
>> + #include "opkg_utils.h"
>> + #include "pkg_hash.h"
>> + #include "opkg_message.h"
>> +@@ -204,7 +205,7 @@ pkg_hash_fetch_unsatisfied_dependencies(
>> + 		    /* user request overrides package recommendation */
>> + 		    if (satisfying_pkg != NULL
>> + 			&& (compound_depend->type == RECOMMEND || compound_depend->type == SUGGEST)
>> +-			&& (satisfying_pkg->state_want == SW_DEINSTALL || satisfying_pkg->state_want == SW_PURGE)) {
>> ++			&& (satisfying_pkg->state_want == SW_DEINSTALL || satisfying_pkg->state_want == SW_PURGE || conf->noinstall_recommends)) {
>> + 			 opkg_msg(NOTICE, "%s: ignoring recommendation for "
>> + 					"%s at user request\n",
>> + 					pkg->name, satisfying_pkg->name);
>> +Index: trunk/src/opkg-cl.c
>> +===================================================================
>> +--- trunk.orig/src/opkg-cl.c
>> ++++ trunk/src/opkg-cl.c
>> +@@ -50,6 +50,7 @@ enum {
>> + 	ARGS_OPT_NODEPS,
>> + 	ARGS_OPT_AUTOREMOVE,
>> + 	ARGS_OPT_CACHE,
>> ++	ARGS_OPT_NOINSTALL_RECOMMENDS,
>> + };
>> +
>> + static struct option long_options[] = {
>> +@@ -89,6 +90,7 @@ static struct option long_options[] = {
>> + 	{"noaction", 0, 0, ARGS_OPT_NOACTION},
>> + 	{"download-only", 0, 0, ARGS_OPT_DOWNLOAD_ONLY},
>> + 	{"nodeps", 0, 0, ARGS_OPT_NODEPS},
>> ++	{"no-install-recommends", 0, 0, ARGS_OPT_NOINSTALL_RECOMMENDS},
>> + 	{"offline", 1, 0, 'o'},
>> + 	{"offline-root", 1, 0, 'o'},
>> + 	{"add-arch", 1, 0, ARGS_OPT_ADD_ARCH},
>> +@@ -199,6 +201,9 @@ args_parse(int argc, char *argv[])
>> + 		case ARGS_OPT_NOACTION:
>> + 			conf->noaction = 1;
>> + 			break;
>> ++		case ARGS_OPT_NOINSTALL_RECOMMENDS:
>> ++			conf->noinstall_recommends = 1;
>> ++			break;
>> +         case ARGS_OPT_DOWNLOAD_ONLY:
>> + 			conf->download_only = 1;
>> + 			break;
>> +@@ -293,6 +298,8 @@ usage()
>> + 	printf("\t--noaction		No action -- test only\n");
>> + 	printf("\t--download-only	No action -- download only\n");
>> + 	printf("\t--nodeps		Do not follow dependencies\n");
>> ++	printf("\t--no-install-recommends\n");
>> ++	printf("\t                      Do not install any recommended packages\n");
>> + 	printf("\t--force-removal-of-dependent-packages\n");
>> + 	printf("\t			Remove package and all dependencies\n");
>> + 	printf("\t--autoremove		Remove packages that were installed\n");
>> diff --git a/meta/recipes-devtools/opkg/opkg_svn.bb b/meta/recipes-devtools/opkg/opkg_svn.bb
>> index 032578d..dbfca0f 100644
>> --- a/meta/recipes-devtools/opkg/opkg_svn.bb
>> +++ b/meta/recipes-devtools/opkg/opkg_svn.bb
>> @@ -1,6 +1,8 @@
>>    require opkg.inc
>>
>> -SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http"
>> +SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
>> +           file://no-install-recommends.patch \
>> +"
>>
>>    S = "${WORKDIR}/trunk"
>>
>>
Paul Barker - Sept. 18, 2013, 3:14 p.m.
On 19 August 2013 19:32, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 8/19/13 1:08 PM, Saul Wold wrote:
>>
>> On 08/14/2013 01:30 PM, Mark Hatle wrote:
>>> +Upstream-status: Pending
>>

I'm the new maintainer for opkg, I'd be happy to look at this patch
and any others if you could send them to opkg-devel@googlegroups.com
via git send-email. I like the idea of both '--no-install-recommends'
and '--add-exclude'.

I stumbled on these as I'm looking at upgrading the opkg recipe to use
the newly released opkg-0.2.0 rather than pulling from subversion.

Cheers,
Richard Purdie - Sept. 18, 2013, 4:07 p.m.
On Wed, 2013-09-18 at 16:14 +0100, Paul Barker wrote:
> On 19 August 2013 19:32, Mark Hatle <mark.hatle@windriver.com> wrote:
> > On 8/19/13 1:08 PM, Saul Wold wrote:
> >>
> >> On 08/14/2013 01:30 PM, Mark Hatle wrote:
> >>> +Upstream-status: Pending
> >>
> 
> I'm the new maintainer for opkg, 

Congratulations! :)

> I'd be happy to look at this patch
> and any others if you could send them to opkg-devel@googlegroups.com
> via git send-email. I like the idea of both '--no-install-recommends'
> and '--add-exclude'.
> 
> I stumbled on these as I'm looking at upgrading the opkg recipe to use
> the newly released opkg-0.2.0 rather than pulling from subversion.

Sounds great!

Nice to see releases and someone looking after opkg a bit more.

Cheers,

Richard
Paul Barker - Sept. 18, 2013, 4:35 p.m.
On 18 September 2013 17:07, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-09-18 at 16:14 +0100, Paul Barker wrote:
>> On 19 August 2013 19:32, Mark Hatle <mark.hatle@windriver.com> wrote:
>> > On 8/19/13 1:08 PM, Saul Wold wrote:
>> >>
>> >> On 08/14/2013 01:30 PM, Mark Hatle wrote:
>> >>> +Upstream-status: Pending
>> >>
>>
>> I'm the new maintainer for opkg,
>
> Congratulations! :)
>

My time for this is fairly limited, but felt it was important that
someone maintain it as it's a critical dependency for a lot of us.

As I understand things the Yocto Project is currently in a
stabilisation cycle. So my plan was to wait until 1.5 is released and
then look at moving oe-core to opkg-0.2.0, adding PACKAGECONFIG
options (I've got a signed package feed I'd like my target to be able
to verify, this needs opkg to be built with --enable-gpg) and whatever
else needs doing. For now the experimental recipes are available from
https://bitbucket.org/opkg/meta-opkg.

As a side question - is there a specific maintainer for opkg-utils?
I'd like to discuss whether two separate repositories is a good idea
or whether we'd benefit from merging this into the opkg repo.
Richard Purdie - Sept. 18, 2013, 4:48 p.m.
On Wed, 2013-09-18 at 17:35 +0100, Paul Barker wrote:
> My time for this is fairly limited, but felt it was important that
> someone maintain it as it's a critical dependency for a lot of us.

We all suffer from time problems so I appreciate someone stepping up
there, it was certainly a gap.

> As I understand things the Yocto Project is currently in a
> stabilisation cycle. So my plan was to wait until 1.5 is released and
> then look at moving oe-core to opkg-0.2.0, adding PACKAGECONFIG
> options (I've got a signed package feed I'd like my target to be able
> to verify, this needs opkg to be built with --enable-gpg) and whatever
> else needs doing. For now the experimental recipes are available from
> https://bitbucket.org/opkg/meta-opkg.

PACKAGECONFIG sounds great but is 1.6 material, yes.

> As a side question - is there a specific maintainer for opkg-utils?
> I'd like to discuss whether two separate repositories is a good idea
> or whether we'd benefit from merging this into the opkg repo.

I can probably speak for it. It was created out of necessity, we had the
situation where patches were piling up against ipkg-utils and since that
was dead, we created a new repository we could merge changes into rather
than having piles of patches.

There are some pretty horrific things in there and it probably needs a
good clean  out, we only use a small part of it. If we have an actively
maintained place for the in opkg, I'd be ok with that. Equally having
them separate does better force sane API decisions (flag days where both
need to change at the same time would be bad for example). If you wanted
commit access to opkg-utils that could probably be arranged if that
helps?

Cheers,

Richard
Paul Barker - Sept. 18, 2013, 5:24 p.m.
On 18 September 2013 17:48, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-09-18 at 17:35 +0100, Paul Barker wrote:
>> As a side question - is there a specific maintainer for opkg-utils?
>> I'd like to discuss whether two separate repositories is a good idea
>> or whether we'd benefit from merging this into the opkg repo.
>
> I can probably speak for it. It was created out of necessity, we had the
> situation where patches were piling up against ipkg-utils and since that
> was dead, we created a new repository we could merge changes into rather
> than having piles of patches.
>
> There are some pretty horrific things in there and it probably needs a
> good clean  out, we only use a small part of it. If we have an actively
> maintained place for the in opkg, I'd be ok with that. Equally having
> them separate does better force sane API decisions (flag days where both
> need to change at the same time would be bad for example). If you wanted
> commit access to opkg-utils that could probably be arranged if that
> helps?
>

I'd rather have opkg and opkg-utils merged together or next to each
other on the same server if/when I move opkg to git. I think
OpenEmbedded/Yocto is probably the main user of opkg but there are
others and they'd also benefit from opkg-utils, so having everything
in one place would make them easier to find.

My personal preference would be to move opkg and opkg-utils to
Bitbucket/Github/similar, probably merged together, with at least one
of the core developers from the Yocto Project having admin access to
the repositories so that the bus factor is greater than 1. I know I
could probably ask for opkg to be hosted on git.yoctoproject.org but I
think that would make non-Yocto Project users feel a little bit too
much like second-class citizens.

I want to avoid flag days where possible, at least one will be needed
for the libopkg API but hopefully not for the command line interface
or package format. I am planning on proposing that opkg explicitly
follow semantic versioning (http://semver.org/) and I think a stable,
sane API is important regardless of whether opkg-utils is separate or
not.
Phil Blundell - Sept. 18, 2013, 6:44 p.m.
On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
> I am planning on proposing that opkg explicitly
> follow semantic versioning (http://semver.org/) 

I'm not entirely sure I understand what you're saying here.  Can you
expand on what the practical effect of "following semantic versioning"
would be?

thanks

p.
Paul Barker - Sept. 18, 2013, 7:09 p.m.
On 18 September 2013 19:44, Phil Blundell <pb@pbcl.net> wrote:
> On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
>> I am planning on proposing that opkg explicitly
>> follow semantic versioning (http://semver.org/)
>
> I'm not entirely sure I understand what you're saying here.  Can you
> expand on what the practical effect of "following semantic versioning"
> would be?
>

I was responding to Richard's comment about flag days. Basically, they
should be very rare and will be announced very loudly if they must
occur. They will result in the major component of the version being
bumped (where the version is of the form "major.minor.patch"). So if
something works with v1.0 of a program, you can be guaranteed that any
v1.x release won't introduce backwards-incompatible changes and break
your script/library/whatever.

Even if opkg-utils is brought into opkg itself, it's a promise that
library functions, command line arguments, config options and control
fields won't disappear or change meaning arbitrarily. "Semantic
Versioning" is just a set of rules that clarify this so that I don't
have to write my own version numbering policy.
Richard Purdie - Sept. 18, 2013, 8:33 p.m.
On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
> On 18 September 2013 17:48, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> I'd rather have opkg and opkg-utils merged together or next to each
> other on the same server if/when I move opkg to git. I think
> OpenEmbedded/Yocto is probably the main user of opkg but there are
> others and they'd also benefit from opkg-utils, so having everything
> in one place would make them easier to find.
> 
> My personal preference would be to move opkg and opkg-utils to
> Bitbucket/Github/similar, probably merged together, with at least one
> of the core developers from the Yocto Project having admin access to
> the repositories so that the bus factor is greater than 1.

FWIW, personally I dislike some of those services as they can be
temperamental and with some of them, I can't actually get a view of the
code in the repos as well as when I'm used to with cgit. I know others
have different preferences, its just life...

>  I know I
> could probably ask for opkg to be hosted on git.yoctoproject.org but I
> think that would make non-Yocto Project users feel a little bit too
> much like second-class citizens.

The Yocto Project is there to be an umbrella for projects serving the
needs of embedded users. Pseudo is an example of something which can be
used standalone, yet it is hosted on the YP servers.

I'd say that opkg would fit under the umbrella and that we'd be more
than happy to host the repo if that was appropriate so the offer is
there. 

Having more varied projects in the umbrella would actually help people
understand what the Yocto Project is verses OpenEmbedded (the build
system/architecture) and Poky (reference distro). We already have others
like eglibc in there but that should be merging back with glibc,
thankfully! :)

> I want to avoid flag days where possible, at least one will be needed
> for the libopkg API but hopefully not for the command line interface
> or package format.

The API has the .so version and can be managed. The package format  in
particular need most careful attention.

>  I am planning on proposing that opkg explicitly
> follow semantic versioning (http://semver.org/) and I think a stable,
> sane API is important regardless of whether opkg-utils is separate or
> not.

Agreed.

Cheers,

Richard
Paul Barker - Sept. 18, 2013, 8:51 p.m.
On 18 September 2013 21:33, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
>> On 18 September 2013 17:48, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> I'd rather have opkg and opkg-utils merged together or next to each
>> other on the same server if/when I move opkg to git. I think
>> OpenEmbedded/Yocto is probably the main user of opkg but there are
>> others and they'd also benefit from opkg-utils, so having everything
>> in one place would make them easier to find.
>>
>> My personal preference would be to move opkg and opkg-utils to
>> Bitbucket/Github/similar, probably merged together, with at least one
>> of the core developers from the Yocto Project having admin access to
>> the repositories so that the bus factor is greater than 1.
>
> FWIW, personally I dislike some of those services as they can be
> temperamental and with some of them, I can't actually get a view of the
> code in the repos as well as when I'm used to with cgit. I know others
> have different preferences, its just life...

I've not had much problems myself but I'll take your word on that. I'm
used to both bitbucket and cgit, don't really have a preference
between the two.

>
>>  I know I
>> could probably ask for opkg to be hosted on git.yoctoproject.org but I
>> think that would make non-Yocto Project users feel a little bit too
>> much like second-class citizens.
>
> The Yocto Project is there to be an umbrella for projects serving the
> needs of embedded users. Pseudo is an example of something which can be
> used standalone, yet it is hosted on the YP servers.
>
> I'd say that opkg would fit under the umbrella and that we'd be more
> than happy to host the repo if that was appropriate so the offer is
> there.
>
> Having more varied projects in the umbrella would actually help people
> understand what the Yocto Project is verses OpenEmbedded (the build
> system/architecture) and Poky (reference distro). We already have others
> like eglibc in there but that should be merging back with glibc,
> thankfully! :)

I'll admit to not fully realising that distinction myself as I've
mostly been looking at OpenEmbedded. If the Yocto Project is more of
an umbrella then yes, opkg probably would fit well within that. I'll
have a think what opkg would need and then get back to you. It would
certainly alleviate the question of what happens to the repository if
I were to disappear. None of us even have full 'owner' access to the
google group opkg-devel as I haven't been able to get hold of the
original opkg creator!

>
>> I want to avoid flag days where possible, at least one will be needed
>> for the libopkg API but hopefully not for the command line interface
>> or package format.
>
> The API has the .so version and can be managed. The package format  in
> particular need most careful attention.
>

Agreed.
Andreas Oberritter - Oct. 7, 2013, 3 p.m.
Hello Paul,

On 18.09.2013 17:14, Paul Barker wrote:
> I'm the new maintainer for opkg, I'd be happy to look at this patch
> and any others if you could send them to opkg-devel@googlegroups.com
> via git send-email. I like the idea of both '--no-install-recommends'
> and '--add-exclude'.

I just tried to submit some unrelated patches, but received a DSN due to
not being subscribed to the opkg-devel group. If I understand correctly,
this would require setting up a google account first.

Would it be possible to lower the hurdles for contribution?

Regards,
Andreas
Paul Barker - Oct. 7, 2013, 4:08 p.m.
On 7 October 2013 16:00, Andreas Oberritter <obi@opendreambox.org> wrote:
> Hello Paul,
>
> I just tried to submit some unrelated patches, but received a DSN due to
> not being subscribed to the opkg-devel group. If I understand correctly,
> this would require setting up a google account first.
>
> Would it be possible to lower the hurdles for contribution?
>

I've set posting to public, we'll see how this goes. Hopefully it
won't result in an increase in spam...

Patch

diff --git a/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch b/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
new file mode 100644
index 0000000..f71b027
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/no-install-recommends.patch
@@ -0,0 +1,78 @@ 
+Add the ability to not install ANY recommended packages.
+
+Upstream-status: Pending
+
+Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
+
+Index: trunk/libopkg/opkg_conf.h
+===================================================================
+--- trunk.orig/libopkg/opkg_conf.h
++++ trunk/libopkg/opkg_conf.h
+@@ -80,6 +80,7 @@ struct opkg_conf
+      int prefer_arch_to_version;
+      int check_signature;
+      int nodeps; /* do not follow dependencies */
++     int noinstall_recommends;
+      char *offline_root;
+      char *overlay_root;
+      int query_all;
+Index: trunk/libopkg/pkg_depends.c
+===================================================================
+--- trunk.orig/libopkg/pkg_depends.c
++++ trunk/libopkg/pkg_depends.c
+@@ -19,6 +19,7 @@
+ #include <ctype.h>
+ 
+ #include "pkg.h"
++#include "opkg_conf.h"
+ #include "opkg_utils.h"
+ #include "pkg_hash.h"
+ #include "opkg_message.h"
+@@ -204,7 +205,7 @@ pkg_hash_fetch_unsatisfied_dependencies(
+ 		    /* user request overrides package recommendation */
+ 		    if (satisfying_pkg != NULL
+ 			&& (compound_depend->type == RECOMMEND || compound_depend->type == SUGGEST)
+-			&& (satisfying_pkg->state_want == SW_DEINSTALL || satisfying_pkg->state_want == SW_PURGE)) {
++			&& (satisfying_pkg->state_want == SW_DEINSTALL || satisfying_pkg->state_want == SW_PURGE || conf->noinstall_recommends)) {
+ 			 opkg_msg(NOTICE, "%s: ignoring recommendation for "
+ 					"%s at user request\n",
+ 					pkg->name, satisfying_pkg->name);
+Index: trunk/src/opkg-cl.c
+===================================================================
+--- trunk.orig/src/opkg-cl.c
++++ trunk/src/opkg-cl.c
+@@ -50,6 +50,7 @@ enum {
+ 	ARGS_OPT_NODEPS,
+ 	ARGS_OPT_AUTOREMOVE,
+ 	ARGS_OPT_CACHE,
++	ARGS_OPT_NOINSTALL_RECOMMENDS,
+ };
+ 
+ static struct option long_options[] = {
+@@ -89,6 +90,7 @@ static struct option long_options[] = {
+ 	{"noaction", 0, 0, ARGS_OPT_NOACTION},
+ 	{"download-only", 0, 0, ARGS_OPT_DOWNLOAD_ONLY},
+ 	{"nodeps", 0, 0, ARGS_OPT_NODEPS},
++	{"no-install-recommends", 0, 0, ARGS_OPT_NOINSTALL_RECOMMENDS},
+ 	{"offline", 1, 0, 'o'},
+ 	{"offline-root", 1, 0, 'o'},
+ 	{"add-arch", 1, 0, ARGS_OPT_ADD_ARCH},
+@@ -199,6 +201,9 @@ args_parse(int argc, char *argv[])
+ 		case ARGS_OPT_NOACTION:
+ 			conf->noaction = 1;
+ 			break;
++		case ARGS_OPT_NOINSTALL_RECOMMENDS:
++			conf->noinstall_recommends = 1;
++			break;
+         case ARGS_OPT_DOWNLOAD_ONLY:
+ 			conf->download_only = 1;
+ 			break;
+@@ -293,6 +298,8 @@ usage()
+ 	printf("\t--noaction		No action -- test only\n");
+ 	printf("\t--download-only	No action -- download only\n");
+ 	printf("\t--nodeps		Do not follow dependencies\n");
++	printf("\t--no-install-recommends\n");
++	printf("\t                      Do not install any recommended packages\n");
+ 	printf("\t--force-removal-of-dependent-packages\n");
+ 	printf("\t			Remove package and all dependencies\n");
+ 	printf("\t--autoremove		Remove packages that were installed\n");
diff --git a/meta/recipes-devtools/opkg/opkg_svn.bb b/meta/recipes-devtools/opkg/opkg_svn.bb
index 032578d..dbfca0f 100644
--- a/meta/recipes-devtools/opkg/opkg_svn.bb
+++ b/meta/recipes-devtools/opkg/opkg_svn.bb
@@ -1,6 +1,8 @@ 
 require opkg.inc
 
-SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http"
+SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
+           file://no-install-recommends.patch \
+"
 
 S = "${WORKDIR}/trunk"