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

Hans-Christoph Steiner hans at at.or.at
Tue Aug 2 16:38:24 UTC 2016



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



More information about the Android-tools-devel mailing list