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

[Hans-Christoph Steiner]

For Android-Tools packages, we need to do packaging updates to make sure
the versions are all in sync.  Like Chirayu said, the Android SDK
packages all need to be built against the exact same version since
that's how upstream builds it, and the libraries and headers are not
versioned at all.  In order to keep this manageable, that means
occasionally pushing packages where we are bumping the upstream version
even though the upstream source only has a different version.  If we try
to manage packages with a range of upstream versions to avoid these
updates, it'll be only add to the management nightmare we already have.

This only affects internal Android SDK packages.  The user facing
packages almost always have updates when the upstream version changes.

.hc


Chirayu Desai:
> On Mon, Aug 1, 2016 at 8:12 PM, Markus Koschany <apo at debian.org> wrote:
>> Hello Chirayu,
>>
>> On 01.08.2016 15:56, Chirayu Desai wrote:
>>> Hello Markus,
>>>
>>> There's one thing about the r55 updates in general.
>>> Previously, the android packages went out of sync, and some were stuck
>>> on slightly older 6.0 revisions. Now most of the time there aren't
>>> many changes, or any significant changes (i.e. code which isn't
>>> android userspace) which would affect us, but there's something once
>>> in a while.
>>> Also, google only builds all of the source code together, with the
>>> same version checked out.
>>
>> I don't understand how this affects Debian. In Debian we package new
>> upstream versions if they contain some sort of newly added files or
>> changes to existing ones. In this case there wasn't any upstream change
>> at all (besides from the version bump). If you only want to update the
>> packaging then you can just bump the Debian revision and be good with
>> it. It doesn't make any sense to package a new upstream release if it
>> doesn't contain any notable changes.
> I agree. This was more of a one-off special case since I scripted the
> update, though I guess
> I could've checked and held off pushing if there weren't any upstream
> changes.
>>
>>> Hence, to avoid confusion, I went ahead and updated all packages to
>>> upstream tag 6.0.1_r55 (latest as of now), and also the Build-Depends
>>> in various packages to the same, as they were even more out of sync
>>> (all were at varying versions).
>>
>> Being out of sync is not a problem as long as the version is just
>> different. It only becomes an issue if packages fail to build from
>> source or stop working because they depend on new or changed code.
> The thing here is there might be subtle bugs when trying to combine
> different versions of upstream code, even if they build / mostly work.
>>
>>> This does bring some problems though, that the packages would always
>>> have to be updated in a particular order, and every time a new
>>> upstream version comes out, they would all need to be updated.
>>>
>>> We could set the BD again manually, relying on manual checking of code
>>> changes, and only bumping it up when necessary - but making sure it
>>> gets done on every upstream update, and for all repos, to not get out
>>> of sync.
>>> And / or perhaps we can make the update / upload process easier
>>> somehow, if updating the 10+ packages in the correct order every time.
>>
>> You only need to update packages if
>>
>> a) upstream has introduced new changes
>> b) another package (build-dependency or dependency) requires this update
>>
>> Setting the correct versioned BD is important in Debian if the package
>> fails to build with an older version.
> Here we were setting it to the latest anyways since that's how upstream is
> usually built.
>>
>> I think it isn't as complicated as you may think it is. You will have
>> less work to do if you only package new upstream releases that contain
>> notable changes. If you don't need to touch a package, great, more time
>> saved for all of us.
> Agreed, by following most of what you listed, and also by adding a simple
> check to the upstream update script most of this can be remedied.
>>
>> Regards,
>>
>> Markus
>>
>>
>> _______________________________________________
>> 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
>  hi
> 
> 
> 
> _______________________________________________
> 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
>