Re: Repackaging android blobs into pkgsrc packages

[Greg Troxel <gdt%lexort.com@localhost>]

David Brownlee <abs%absd.org@localhost> writes:

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

Here, I think the big question is about maintenance and security
updates.  We have seen e.g. that with ghostscript-gpl, maintenance did
not happen.

Aleksej:

So I would tend to say that if you want to set up a new public upstream
of qt5-lgpl2 with a bug tracker and maintenance releases, and actually
maintain it, then I see no issue with having a package for this fork.
Certainly multiversion support, with namespaces, seems nicer, although
I'm not sure how the need for an old lpgl2 version balances with the
burden on what I expect is the majority having a namespaced version.  So
perhaps if namespaced, it should be like guile where /usr/pkg/qt5-lgpl2/
is a prefix for the old version, and the current release is at the
normal name.

I am not a fan of forking software *in pkgsrc* and then not having it be
maintained.  So I am more or less opposed to just reimporting old
versions with the intent that they stay forever.  (We do have old
versions until they are no longer needed, like for guile and other
programs that break compatibility or where the new versions don't run
well in some environments.)