[OE-core] [PATCH 08/11] opkg: Add --no-install-recommends option.

[Richard Purdie]

On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
> On 18 September 2013 17:48, Richard Purdie
> <richard.purdie at 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