Re: Repackaging android blobs into pkgsrc packages

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

On 2019-02-04 23:24, David Brownlee wrote:
> On Mon, 4 Feb 2019 at 17:23, Aleksej Lebedev <root%zta.lk@localhost> wrote:
>
> > 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)?
>
> Would you anticipate setting up something like
> "QT5_VERSIONS_INCOMPATIBLE=56" similar to
> PYTHON_VERSIONS_INCOMPATIBLE, or is this just to build your own
> internal tools against?

Currently, just to build our own internal tools.

> I think if it is able to be installed and run concurrently with qt-5.7
> (or later) on a machine, then as it has a valid use case (licence),
> and if its actively maintained and doesn't cause issues for bulk
> builders it should be welcomed into pkgsrc (but someone closer to the
> coalface may have a more relevant opinion :)

Thanks for you answer. All of what you said can be done, but I am not 
sure
if I will be able to maintain it well enough. As Greg mentioned in his
reply (I agree with him), forking software in pkgsrc is probably not
the best thing unless there is a real need (other packages require it)
and the fork is well maintained.

> David

--
Aleksej Lebedev