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

Hans-Christoph Steiner hans at at.or.at
Tue Aug 2 11:03:39 UTC 2016



Markus Koschany:
> On 02.08.2016 12:23, Hans-Christoph Steiner wrote:
>>
>>
>> Markus Koschany:
>>> On 02.08.2016 09:38, Hans-Christoph Steiner wrote:
>>> [...]
>>>>
>>>> Markus Koschany:
>>>>> On 01.08.2016 22:00, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>>
>>>>>> Markus Koschany:
>>>>> 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
>>> [...]
>>>
>>> How can this have an effect on packages if headers and macros have not
>>> changed at all?
>>
>> If the source code has not changed at all, then it obviously will not
>> affect the code.
> 
> Thank you for your acknowledgment. That means it is not possible that
> the old upstream release could have caused any build failures because
> nothing has changed.
> 
>>  In that case, we are uploading packages with new
>> upstream versions so that all of the Build-Depends versions can use the
>> exact same upstream version.  In order to catch errors in the upload
>> order, we set the version in Build-Depends.  It would be a nightmare to
>> manage those versions if we kept different upstream versions for the
>> various Android SDK packages.
> 
> android-libunwind-dev has just one reverse build-dependency,
> android-platform-system-core. It would have been sufficient to change
> the Build-Depends line
> 
> android-libunwind-dev (>= 6.0.1+r55~) [amd64 i386] <!stage1>,
> 
> to
> 
> android-libunwind-dev (>= 6.0.1+r16~) [amd64 i386] <!stage1>,
> 
> 
> I think calling that a nightmare is stretching things a little. The same
> goes for android-libselinux-dev.

You're looking at one package, not the whole picture.

.hc



More information about the Android-tools-devel mailing list