Aleksej Lebedev <root%zta.lk@localhost> writes:
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.
I'm not sure I am following.
If you mean:
The plan for using Android SDK installed via pkgsrc is that pkgsrc's
update mechanisms will be usd, and the built-in update path in the
SDK
will be disabled.
that sounds fine.
If you mean something else, I don't understand.
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?
We do not require that in general for non-Free packages, but if there
isn't a way to just wget the tarball, pkgsrc should indeed error out
and
let the user choose to deal or not deal. We do not engage in clicking
yes for people on web pages. So yes, what you are suggeesting sounds
fine.