[Android-tools-devel] RFS: android-platform-external-libunwind/6.0.1+r55-1

[Hans-Christoph Steiner]

Markus Koschany:
> On 01.08.2016 20:53, Hans-Christoph Steiner wrote:
>>
>> For Android-Tools packages, we need to do packaging updates to make sure
>> the versions are all in sync.  Like Chirayu said, the Android SDK
>> packages all need to be built against the exact same version since
>> that's how upstream builds it, and the libraries and headers are not
>> versioned at all.  In order to keep this manageable, that means
>> occasionally pushing packages where we are bumping the upstream version
>> even though the upstream source only has a different version.
> 
> Then our current updating process is obviously flawed because there
> shouldn't be any difference in building against version 1.0 or 1.1
> provided both versions are identical.
> 
>> If we try
>> to manage packages with a range of upstream versions to avoid these
>> updates, it'll be only add to the management nightmare we already have.
> 
> I guess I need a concrete example to understand the management
> nightmares. I'm quite sure that this is easily solvable.
> 
>> This only affects internal Android SDK packages.  The user facing
>> packages almost always have updates when the upstream version changes.
> 
> In my opinion it doesn't really matter if we divide packages into "for
> internal use" or "user facing" packages. They are all part of Debian and
> the same guidelines and rules apply everywhere. That would be just a
> waste of disk space on snapshot.debian.org. The version number really
> can't be the decisive argument why a package can be built or not.
> 
> Regards,
> 
> Markus


Its unfortunately not easily solvable.  We have two options as I see it,
either have to build it like upstream does, meaning one giant source
package that we update and reupload for any small fix, even a tiny
security fix.  Or do what we are doing: break up the packages mostly
along the lines of the upstream git repos so that we can do security
fixes without re-uploading the whole giant thing.

We're dealing with libraries that have no stable API, neither source nor
binary.  A bugfix release can change a header that lots of things are
built against.

This is not something we have done rashly, we've discussed this at
length over a couple years.  We're also on our 3rd architectural
approach.  We've tried to avoid as much badness as we could, this is
where we have gotten.

.hc