Re: Repackaging android blobs into pkgsrc packages

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

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.