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

[Hans-Christoph Steiner]

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 can't look at this one line in your example without considering all
of the intertwined packages with multiple circular dependencies.  We
need to be able to script updates in order to have a chance of doing
this elaborate upload procedure in a reliable way.  That means changing
the Android SDK Build-Depends: in a scripted way.  That gets a lot
harder if we have to manage multiple upstream versions which are
supposed to be the exact same version, since that's the only way
upstream ever builds it.

If you want to write the scripts and create the procedure to upload the
Android SDK, then you can do it anyway that you see fit.  We're doing
the best we've come up with considering all of the issues, and there are
many.


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

I really don't understand the problem here, I'm sorry if I angered you.
You're coming in at the end of a long process.

.hc