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

[Hans-Christoph Steiner]

Markus Koschany:
> On 01.08.2016 21:30, Hans-Christoph Steiner wrote:
> [...]
>>
>> 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.
> 
> I thought we were looking for the best technical solution. Of course a
> bugfix release can change a header or some other things, agreed, but in
> this specific case nothing has changed. How can this be a management
> nightmare?

Sometimes the best technical solution is a choice between bad options.
That's life.  To understand why, consider that we need to build all C
code against libs and headers with the exact same version.  Some source
packages have circular dependencies.  For more details, dig into the
archive of this list.  There has been a lot of discussion on this topic,
and its also on the wiki some.


> If the students had asked on debian-mentors for sponsorship everyone
> there would have pointed out the same.
> 
> I would have welcomed it if we had found a better solution and indeed
> your way of handling this was way too pushy.

We've been uploading packages like that for a year now, its nothing new.
 I didn't know that you didn't know.

.hc