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

Tue Aug 9 07:48:06 UTC 2016

Hi,

IMHO, I don't think it is necessary to upload a new upstream release
if the code hasn't changed at all.

In fact, we do not gain too much in forcing syncing all AOSP packages
to the exact same version. Google frequently makes small changes to
AOSP, no matter for bug fixes or security enhancements, they won't
make changes to every single projects of AOSP. But most of the AOSP
projects shares the same version scheme, that's why some projects
still get new versions even if they do not change.

Therefore, most of the packages, especially those
android-platform-external-* packages, won't change during minor
revision releases. In that case, we can leave them as is and update
those packages that really got their code updated.

Forcing to sync the version of every package would give maintainers a
burden. Imagine that one day AAPT receives a serious security patch
and a new AOSP revision is released, but in this release other
projects have no change at all. I hope that when we come to this
situation, we can simply swiftly upload a new upstream release of
src:android-platform-frameworks-base instead of uploading every AOSP
packages all over again. By the time the new AAPT hits Debian Testing,
hackers already got what they want.

There is no such nightmare when you manage the Build-Depends, as I am
the maintainer of many AOSP package and I understand them. Just
because AOSP packages have very complicated relationships between one
another, Build-Depends on too strict versions would often prevent us
updating the packages.

The automatic upstream-importing script written by Chirayu is a great
tool, we can use it to swiftly updating the UNRELEASED codes on Alioth
to the latest upstream release. Then we can pick those who really
receives code changes to release and upload to Debian. Thus we can
swiftly get the latest patches from AOSP. Now that AOSP reaches
6.0.1_r63, I don't want to update any one of them because the huge
update is a huge process.

In brief:
  1. Either frequent updates on selected package, or non of them will
get updates.
  2. As long as the code hasn't changed, building against old versions
won't hurt.

Cheers,
Kai-Chung Yan

2016-08-03 3:02 GMT+08:00 Hans-Christoph Steiner <hans at at.or.at>:
>
>
> 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
>
> _______________________________________________
> Android-tools-devel mailing list
> Android-tools-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel

-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/