pkgsrc-Users archive

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

Re: Repackaging android blobs into pkgsrc packages



On Fri, 8 Feb 2019 at 10:32, Aleksej Lebedev <root%zta.lk@localhost> wrote:

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

If you're going to be depending on it on an ongoing basis it may make
sense to create a github copy of the qt-5.6 repo - certainly it would
make it easier to manage any patches you accumulate over time. You
might even find that others have a similar need and you get a (very)
occasional PR with fixes :)

You could them have the pkgsrc build for it in pkgsrc-wip or even
another small repo ("pkgsrc-tomtom"? :) which could be dropped into
any checked out pkgsrc tree by anyone interested...

David


Home | Main Index | Thread Index | Old Index