Hello, Am 01.03.2016 um 19:07 schrieb toogley: > Hello. > > > Context of my question: > ====================== > > i want to package android studio. In the android studio package request > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747614 is intellij > idea marked as blocking bug. > I consider > a) android-studio and intellij idea as quite independent, i.e. i think > we don't need to package intellij idea first (but i'm at still unsure > about it) and Probably you don't have to package the whole IntelliJ IDE. Most recently I have packaged intellij-annotations because I needed it as a build-dependency for android-platform-tools-base. Especially for large and complex projects like IntelliJ (last time I checked I noticed that the source release bundles ~500 jars), it is often simpler to package certain parts from maven central instead of trying to build everything. > b) android-studio as more important, because for developing java are > alternative IDE's available , but for developing android mostly none. > But that's just an personal estimation. Packaging android-studio for Debian would certainly be a nice addition. Netbeans or an up-to-date Eclipse IDE should be able to accomplish most of the tasks too as soon as all other Android components are packaged for Debian though. > actual question > =============== > > 1) removing teamcity build dependency > > jetbrains is building their idea with teamcity, their commercial > continuous integration service. Because the build script from > android-studio hasn't changed, i guess they do the same. Although > jetbrains is allowing open source projects to use teamcity freely, the > license is still non-free - which makes it unsuitable for debian. > Therefore i want to remove it, but I don't know how i can systematically > remove it. I'm not sure if its the "best" way to just try to remove all > teamscript related scripts/tests. I suggest to refrain from packaging the complete IntelliJ IDE for now, except you are really dedicated to this task and want to maintain this package for the foreseeable future. I would go for packaging single maven artifacts instead. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature