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

[Markus Koschany]

On 02.08.2016 18:38, Hans-Christoph Steiner wrote:
> 
> 
> Markus Koschany:
>> On 02.08.2016 13:03, Hans-Christoph Steiner wrote:
>>>
>>>
>>> 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.
>>
>> I'm looking at the issue at hand and I presented the solution how you
>> could have avoided to upload two packages without upstream changes. On
>> the other hand you haven't presented any argument in this thread why it
>> would be necessary in Debian to upload new upstream releases without a
>> single change. I think I have made my point. Unfortunately you were not
>> interested in it. Just ignoring valid objections cannot be the basis for
>> fair and respectful conduct towards one another.
>>
>> Regards,
>>
>> Markus
> 
> We've had a long thread here, nobody is ignoring what you've said.
> 
> .hc

Right. After you had created the facts.

Thanks


-------------- 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/77e8ac6d/attachment-0001.sig>