Re: Repackaging android blobs into pkgsrc packages

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2018-12-21 at 16:06 GMT, Aleksej Lebedev wrote:

> I work at TomTom and we are using pkgsrc internally to reproduce the same
> developement environment on different versions of Ubuntu and MacOS.

Neat!

> Pkgsrc serves this purpose very well, however there are some packages that
> are not very portable or hard to build from scratch or simply missing in
> pkgsrc. So we have
> a separate repo for those. I wander if it's worth sharing this work with the
> world (if not to the official pkgsrc or pkgsrc-wip).
> 
> Here is what we have:
> 
>     plantuml
>     proguard
>     protobuf26 (because it's incompatible with protobuf 3 and we need the
> old one)
>     py-clang-gcov-fix
>     py-multimethod2 (the same as py-multimethod but our own fixes)
>     ruby-asciidoctor-pdf
>     android-ndk
>     android-platform-{14-28}
>     android-build-tools
>     android-platform-tools
>     p4v
> 
> All android packages are simply (re-)packaged tarballs of the original
> google blobs. As I understand they don't belong to pkgsrc. Nevertheless they
> might be usefull for somebody, is there a good place for them?

We also have a separate repository for packages that we're either
working on, are older releases, or aren't suitable for upstream
pkgsrc, it's available here:

  https://github.com/joyent/pkgsrc-joyent/

and git submodule'd into pkgsrc/joyent.  I suggest doing something
similar, though we're occasionally guilty of keeping things in there
that should be upstreamed, so it's worth trying to avoid that.

The android packages might be useful.  I'd gauge interest by comparing
other package managers, if something like Homebrew ships them then
it's worth us having them too to avoid our users potentially switching
away from pkgsrc if they can get all they need from somewhere else.

Cheers,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com