[Android-tools-devel] RFS: android-platform-external-libunwind/6.0.1+r55-1
Chirayu Desai
chirayudesai1 at gmail.com
Fri Aug 19 12:34:35 UTC 2016
Hi,
On 08/09/2016 01:18 PM, 殷啟聰 wrote:
> Hi,
>
> IMHO, I don't think it is necessary to upload a new upstream release
> if the code hasn't changed at all.
Agreed.
>
> 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.
Right. We should still try to keep it updated to the latest version the
best we can.
And also keep Build-Depends in sync.
>
> 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.
Agreed completely.
>
> 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.
Yes. However we should still ensure that every package has the latest
version possible, and that all the Build-Depends also point to the
latest version packaged / needed.
>
> 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.
Being not strict would also cause issues, we should find a middle ground
here.
>
> 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.
I think we could set a policy here that everybody would agree on.
What I suggest:
1) Make sure Build-Depends always uses the latest version available in
Debian.
2) Always *try* to update packages using the script (it's in the scripts
repo on alioth),
and commit / upload it if there are changes in the upstream code.
Otherwise it would still be a good idea to run that locally every time
there's a new release to check for changes and also to make sure that
the scripts still work.
This could be put on a wiki.
Right now we have 6.0.1+r55 as the Build-Depends in all packages,
however some are still on r16 or r43. I think it would be okay to lower
that if there are no upstream code changes in the last version, as long
as that is strictly enforced. It would have to be manual though, and not
just a revert of the 'update Build-Depends to r55' commit since the
version set previously was as old as 6.0.0+r26 in some cases.
I'm looking at [1] and the changes on the upstream branch to get an idea
of what should be changed. This could also potentially be automated (if
during an upstream update there are code changes, also update
Build-Depends in other packages when that is updated)
Regards,
Chirayu Desai
[1]:
https://qa.debian.org/developer.php?login=android-tools-devel%40lists.alioth.debian.org
>
> 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
>
>
More information about the Android-tools-devel
mailing list