Wolfgang Wiedmeyer:
>
> Hans-Christoph Steiner writes:
>
>> Thanks Wolfgang for pushing this forward! I'm a big fan of merging
>> efforts and working on a common set of Android SDK packages. We have
>> put a ton of work getting to the point where we everything is built from
>> DFSG-free source. Most of this work will directly apply to other
>> distros, but some will not.
>>
>> There are a couple of spots that would be great to have some
>> cross-distro collaboration on. For example, an ant build for the core
>> of gradle. Right now, gradle builds gradle, which makes it very hard to
>> get started, among other issues. It should be possible to make a basic
>> ant build of the core of gradle which builds just enough to then build
>> gradle with.
>
> I learned this the hard way when I tried to backport gradle for my own
> use when it was only available in unstable. How did you then do the
> upload to backports? AFAIR there were build errors when I tried to build
> it with the version in Jessie. Are these circular dependencies the biggest
> challenges or maybe the only really difficult parts for uploading to
> Debian based distros? Are circular dependencies among the Android
> packages documented somewhere, also the approach you chose for uploading
> these packages to Debian?
> We could include the ant build of core gradle as an example for this in
> the post.
I wasn't involved in the initial gradle upload to Debian. gradle 1.5
was already in Debian when we started.
If I was starting from scratch, I would probably combine packages into
two source packages, based on how upstream tags and releases them
* tagged after AndroidOS releases, e.g 7.0.0r32
* tagged after Gradle Android Plugin, e.g. gradle_2.3.0
The best way is to have a discussion, since there are lots of annoying
technical details. We, the Debian Android Tools Team, are happy to
discuss with anyone. Email list and IRC are the best way:
https://wiki.debian.org/AndroidTools
The one circular dependency is also documented there in the "updating"
section.
.hc
>> Java people like to do this kind of crap. Lombok also depends on itself
>> for the build, we took a similar approach there.
>
> Yeah, I came across similar cases although I don't remember specific
> ones and I was wondering if there was a trait to it.
>
> Best regards,
> Wolfgang
>
>> .hc
>>
>> Wolfgang Wiedmeyer:
>>> Hi all,
>>>
>>> some of you might already have noticed that I was spouting my opinion
>>> about how it's not worth working on a Replicant 6.0 SDK over thlast
>>> months[1][2]. But we never had a final verdict among Paul, Denis and me
>>> or the community as a whole about this. I think we should decide if it
>>> should still be a priority to create a SDK or if it should be something
>>> that someone can create if they feel to, but it's not a goal that is
>>> actively pursued by the project.
>>>
>>> I will summarize my reasoning again below why I don't think that it's
>>> worth it to work on this. I just like to have the decision on this
>>> before the Replicant 6.0 release, so this can be addressed in the
>>> release blog post. It might even warrant its own blog post and I would
>>> prefer to do a dedicated post about it if we agree on my proposal.
>>>
>>> The Android SDK is packaged in Debian, even the same API as the
>>> Replicant 6.0 SDK would have. Debian even has build tools packaged that
>>> are not available in the SDK, like gradle or the gradle plugin. Some
>>> advantages of the Debian Android SDK over a Replicant 6.0 SDK:
>>> * properly build from source without relying on Google's prebuilt
>>> binaries
>>> * build is reproducible
>>> * only an "apt-get install android-sdk" away
>>> * Debian developers actively work on packaging more target APIs,
>>> something we basically can't do
>>> * Debian Android SDK is exposed to a lot more users and has more
>>> developers, so there will be less bugs and they are fixed a lot faster
>>> * Debian developers have packaged or are packaging more tools and
>>> libraries that would not be available in a Replicant 6.0 SDK
>>>
>>> So my proposition is to not work on a Replicant 6.0 SDK, but to get the
>>> Debian Android SDK into more distributions, especially GNU
>>> FSDG-compliant ones. A blog post could address this and encourage users,
>>> that are interested in a Replicant 6.0 SDK, to work with the developers
>>> of the distro they are using to get the Debian Android SDK packaged in
>>> their distro. If we agree on this strategy, it would be good to clarify
>>> some of the things below before writing a blog post, so we can provide
>>> more specific instructions on how this goal can be reached.
>>>
>>> Is it correct that Trisquel and Parabola are the most popular
>>> FSDG-compliant distros? It looks like the next release of Trisquel (8.0
>>> Flidas) will be based on Ubuntu 16.04. Ubuntu 16.04 has the android-sdk
>>> packaged[3], but it's not complete as some packages didn't make it in
>>> time. android-sdk-platform-23 which is the actual target platform is
>>> only in Zesty (17.04)[4]. Are there some Trisquel folks reading along
>>> that could chime in on this? Would it be possible to get the rest of
>>> the needed Android packages included in Flidas by backporting them from
>>> newer Ubuntu releases? Are there other procedures to get packages
>>> uploaded and included in a Trisquel release? The SDK will likely end up
>>> in Trisquel at some point in the future, but it will probably take a
>>> very long time without doing something about it now.
>>>
>>> Hans-Christoph Steiner from the Debian Android Tools team addresses
>>> uploading to other distros in a mail[5]. I didn't yet see any efforts to
>>> get the SDK properly packaged in Arch Linux or in Parabola for that
>>> matter. Arch only seems to have packages that download the SDK from
>>> Google's servers without building it from source. Maybe some Parabola or
>>> Arch folks can comment on this? What would be the best strategy to get
>>> the packages into Arch? I guess if they are in Arch, they will show up
>>> in Parabola as well, at least eventually.
>>>
>>> Best regards,
>>> Wolfgang
>>>
>>> [1]
>>> http://lists.osuosl.org/pipermail/replicant/Week-of-Mon-20170320/001247.html
>>>
>>> [2]
>>> https://lists.alioth.debian.org/pipermail/android-tools-devel/2016q4/002316.html
>>>
>>> [3] http://packages.ubuntu.com/xenial/android-sdk
>>>
>>> [4] http://packages.ubuntu.com/zesty/libandroid-23-java
>>>
>>> [5]
>>> https://lists.alioth.debian.org/pipermail/android-tools-devel/2016q4/002325.html
>>>
>
>
_______________________________________________
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant
