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

[Hans-Christoph Steiner]

Markus Koschany:
> On 01.08.2016 22:00, Hans-Christoph Steiner wrote:
>>
>>
>> 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.
>>
> 
> Please provide a concrete example where this has ever been an issue. We
> are talking about one source package with two different Debian versions
> but with identical code base. I'm honestly interested to learn more
> about this scenario because I have never faced such a problem before.

Off the top of my head, here are a couple of cases where all things that
use it need to be recompiled against the new one or the code will not be
the same:

* function definition changes in a header file
* C macro in a header file
* contents of an #ifdef block changes in a header file
* an inline function in a header file


>>> 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.
> 
> How could I when you are the one who uploaded the packages. This was the
> first time when someone asked me to upload a new upstream version
> without upstream changes. Some people would call that odd.
> 
> Sorry this is not what I would call a collaborative effort to solve an
> issue. The freeze is months away and there would have been enough time
> to talk about this. Don't count me in anymore.

As far as I know, I was uploading all of the C-based android-tools
packages until the last month or so.  We only started the 6.0.1_r55
recently.  We did the same procedure in the winter when we did 6.0.1_r15.

.hc