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

[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.

Regards,

Markus


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20160802/a6ea318c/attachment.sig>