Bug#790978: [Android-tools-devel] Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
We are in the process of updating all of the android-platform-* packages. It is a large, complex suite so it takes time. If you need to force the transition, just go ahead and ignore this package. The update is more or less done, we are currently just wanting on this dependency in a different library that we do not maintain: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793863
Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
This is friendly ping wrt the libstdc++ ABI transition. Your package is listed as needing a transition but has seen no action. It'd be good to get things going so we can finish the transition soon. Cheers, Emilio
Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
All of the android-* packages must be updated to the latest version at the same time. It is more unpredictable to have android-* packages at different upstream versions since no one is running that configuration, and upstream does not do anything to support that (e.g. no versioned ABI, etc). Therefore, the ABI is guaranteed to be compatible since they'll all be built together. In practice, this means that the process of updating to the latest upstream version has to start from the most core packages, then progress to the ones that depend on it. That said, this private shared library arrangement allows for security patches in the android shared code to be applied without having to rebuild everything. signature.asc Description: OpenPGP digital signature
Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
On Wed, Aug 19, 2015 at 13:14:18 +0200, Hans-Christoph Steiner wrote: All of the android-* packages must be updated to the latest version at the same time. It is more unpredictable to have android-* packages at different upstream versions since no one is running that configuration, and upstream does not do anything to support that (e.g. no versioned ABI, etc). Therefore, the ABI is guaranteed to be compatible since they'll all be built together. In practice, this means that the process of updating to the latest upstream version has to start from the most core packages, then progress to the ones that depend on it. That said, this private shared library arrangement allows for security patches in the android shared code to be applied without having to rebuild everything. It does require that you version your dependencies appropriately, though, so that a non-working combination is not installable. Cheers, Julien signature.asc Description: Digital signature
Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
On Tue, 11 Aug 2015 at 08:49:16 +0200, Julien Cristau wrote: This function changes with the new libstdc++: std::string pseudolocalize_string(const std::string source); android-libhost thus needs to be renamed. android-libhost is a semi-private library not in the default linker path, and doesn't have a proper SONAME (Android doesn't really do ABI, the upstream assumption is that you rebuild the entire OS image every time). My understanding is that it is not meant to be renamed for any other incompatible change either. As such, maybe a sourceful upload of android-platform-build with versioned Breaks on the only rdep (aapt), followed by a binNMU of aapt's source package android-platform-frameworks-base, would be more appropriate? Longer term, stuff from upstream Android with no real ABI should probably be a single source package (perhaps using dpkg-source 3.0 (quilt)'s support for multiple orig tarballs) so that it can be rebuilt as a unit, and have lockstep dependencies. S
Bug#790978: [Android-tools-devel] Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
This should be addressed once we update all of the android-platform-* source packages to the latest version from Google (5.1.1+r8). Simon is right in that these are basically private libraries. Upstream statically links them into each executable. That didn't seem very Debian-ish, so instead I structured it as private shared libraries. Nothing should link to these android-lib* shared libraries that is not part of the Android source. A single source package might make some things easier, but it would be about 8-12 gigs in size. That would make it very difficult for many people to work with that source package. .hc signature.asc Description: OpenPGP digital signature
Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
On 19/08/15 10:40, Hans-Christoph Steiner wrote: Simon is right in that these are basically private libraries. Upstream statically links them into each executable. That didn't seem very Debian-ish, so instead I structured it as private shared libraries. Nothing should link to these android-lib* shared libraries that is not part of the Android source. To be honest that sounds to me like a job for static libraries and Built-Using. If shared libraries with a stable ABI are not feasible, static libraries are probably a better fallback position; shared libraries with an unpredictable ABI seem like the worst of both worlds. S
Processed: Re: Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default
Processing control commands: severity -1 serious Bug #790978 [src:android-platform-build] android-platform-build: library transition may be needed when GCC 5 is the default Severity set to 'serious' from 'important' tag -1 confirmed Bug #790978 [src:android-platform-build] android-platform-build: library transition may be needed when GCC 5 is the default Added tag(s) confirmed. -- 790978: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790978 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
