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

[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




-------------- 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/2fa3b700/attachment.sig>