Re: Repackaging android blobs into pkgsrc packages

[Aleksej Lebedev <root%zta.lk@localhost>]

On 2018-12-21 17:58, Greg Troxel wrote:
> 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.

Thanks for your answer. Makes sense. I will consider committing some 
parts to wip.

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

Android SDK's own update mechanism would probably interact with pkgsrc 
very badly.
But it's not assumed to be used in this case.

> > 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).

It's distributed under a separate lincense. Should I do the same trick 
as lang/oracle-jdk8 does?
I.e. ask user to download the binary manually and put it to distfiles?

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

It seems to me that gnu-lgpl-v2.1 is wrong as the following blog post 
says
"So Qt 5.7 will not be available under LGPLv2.1 anymore":

http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/)

I don't fully understand all specifics of licensing (I am an engineer, 
not a lawyer),
but the problematic part seems to be this one (from the same blog post):

LGPL version 3 differs from version 2.1 in two fundamental aspects. It 
explicitly protects the right of the end user to not only compile their 
modifications, but also deploy and run them on the target device. This 
essentially prevents the creation of fully locked-down devices.

Specifically, the problem is that lgpl-3 prevents so-called tivoization.

Anyway, the license does matter to us. So we will have to maintain 
qt-5.6.
I was wandering if pkgsrc community wants to see it as a separate entity 
(x11/qt56)?

--
Aleksej Lebedev