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

[Paul Barker]

On 18 September 2013 17:48, Richard Purdie
<richard.purdie at 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.

-- 
Paul Barker

Email: paul at paulbarker.me.uk
http://www.paulbarker.me.uk