With Android SDK 1.6 came the SDK and AVD manager which can conveniently download and update the SDK among other things. It's own package manager! The current ebuild doesn't really allow for this. I've tried given the android-sdk folder in /opt/ write permission for the group but I get the following error within eclipse: Unzip failed: Cannot run program "chmod": java.io.IOException: error=24, Too many open files Either need a version bumb in portage to android sdk 2.0 (ignore the built in package management) or a revamp allowing the sdk to look after itself. Reproducible: Always
This unzip falied error seems to be a problem with running the update through eclipse. Running the manager from the console avoid the problem - so that's a bug for eclipse, not Gentoo, sorry. http://groups.google.com/group/android-developers/browse_thread/thread/814e3c898d7b24fc?hl=en# However, I still feel the current ebuild needs at least an elog to notify about the update manager, or a solution.
I'll see if we can get a bump to 2.0 in. I'm not sure that we're ever going to be able to support self-updating packages like this - it would create a mess with the package database and uninstalling the SDK would not work, among other things. The best we could do is a separate package that only installs the installer which would then have a private area it could work in. Not sure how practical that would be. It also sort-of defeats the purpose of having a centralized package manager in the first place.
Created attachment 210277 [details] ebuild for android-sdk-2.0 I have made an ebuild for the version 2.0
I'm a little concerned about the upstream filename here - android-sdk_r3-linux.tgz doesn't have a 2.0 in it at all. The main concern is that we can't have cross-version file collisions, and I'm not sure how stable that file is. For most projects I'd probably just mirror the tarball and give it a more sensible name. However, the android license doesn't allow us to redistribute this one. It seems like their new approach is to distribute the "SDK Tools" and this is revision 3. I'm actually tempted to call this ebuild android-sdk-3.0.ebuild as a result. The SDK 2.0 is just one of several packages that it can download and install. Note that cleaning will not remove any files downloaded from the SDK tools. This is really not a very clean way to handle things from a distro perspective. Unfortunately, we're very limited in our ability to fix it due to the license. Only way I can see is to figure out URL the tools download from and point to that instead.
*** Bug 293410 has been marked as a duplicate of this bug. ***
Created attachment 210477 [details] Updated ebuild Slightly updated ebuild.
(In reply to comment #4) > I'm a little concerned about the upstream filename here - > android-sdk_r3-linux.tgz doesn't have a 2.0 in it at all. It wouldn't be a problem if we just added a new package - then the -r3 could be turned into a simple -3. It's not like you are installing the SDK anyway - it's just the update manager. We might then do a pkgmove from dev-util/android-sdk to dev-util/android-sdk-update-manager...
Created attachment 210478 [details] Correct updated ebuild Whoops - maybe I'll upload the right file this time... I'm going to go ahead with v3 here, since that is what upstream is calling the sdk tools. Ideally I'd rename the package as well, but that is probably a bit overkill since this is now the only way to get the sdk.
Ok, in cvs, but the package is renamed to android-sdk-update-manager. Portage should automatically update your config files...
