pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Repackaging android blobs into pkgsrc packages



Aleksej Lebedev <root%zta.lk@localhost> writes:

> 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

I would say that unless things are clearly inappropriate for pkgsrc
proper, I would tend to put them there (or wip if they are not stable),
rather than putting them in an add-on repo.

> 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?

I guess the big question there is how they get updated, and how that
compares to the upstream update cycle, and how many are likely to want
them.  If the Android SDK is easier to run on NetBSD (under linux
emulation??) because of these packages, I'd say that's a win.  But I'm
not sure how the Android SDK's own update mechanism would interact with
pkgsrc.

> P4V is also a repackaged binary of the Perforce visual client.

We have packages for proprietary software, so this seems to fit
(although very likely it will not be redistributable, it can be useful
locally).

> While here, I have a question regading qt5. Pkgsrc jumped over 5.6
> long time ago, but as I recently learned QT switched to a different
> license after 5.6 which make it impossible for us to use the most
> recent version provided by pkgsrc. My question is doesn't it affect
> pkgsrc too? And was there a plan to include qt-5.6 in pkgsrc as a
> separate package?

The license tag on qt5 says

  gnu-lgpl-v2.1 AND gnu-gpl-v3

which doesn't seem that odd.  Can you explain the issue more
specifically?  I wonder if our tag is wrong (quick search gives hints of
lgpl 3, not 2), and if your problem is gpl2/3 compatibility, or
something else.


Home | Main Index | Thread Index | Old Index