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

[Hans-Christoph Steiner]

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

I should add: I'm open to ideas how to better handle this.  At this
point, we need to get 6.0.1_r55 uploaded with the strategy we have
worked out over the past year or two so we have enough time to get the
whole thing uploaded before the end of GSoC.

Any new approaches would have to come after 6.0.1_r55 is fully uploaded.

.hc