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

Sat Aug 20 13:54:59 UTC 2016

Hi,

I would like to add something here. I've been trying to get things
uploaded, and for that I was making sure the Build-Depends are satisfied
and the relevant repositories are already uploaded.
One thing I didn't realise initially was that updating everything at the
same time would lead to cross dependencies and an unsolvable conflict.
Example:

src:android-platform-build B-Ds on pkg:android-libandroidfw-dev provided
by src:android-platform-frameworks-base
src:android-platform-frameworks-base B-Ds on
android-platform-build-headers which is provided by
src:android-platform-build

Trying to update the B-Ds for both of them after doing an upstream
update would leave us in a state where none of the packages would be
uploadable (i.e. right now). I'm fixing this, as I was the one who
caused this in the first place. Sorry for the trouble.

One thing we could do is make sure to update the B-Ds after an upload is
done. So that when we have all packages on r55, the B-Ds in git /
UNRELEASED are also at r55, if they weren't already required to be
before the upload. This is something best left to scripts I would say,
given we set a certain criteria / policy.

On 08/19/2016 06:04 PM, Chirayu Desai wrote:
> 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
>>
>