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

[Markus Koschany]

On 01.08.2016 22:00, Hans-Christoph Steiner wrote:
> 
> 
> Markus Koschany:
>> On 01.08.2016 21:30, Hans-Christoph Steiner wrote:
>> [...]
>>>
>>> Its unfortunately not easily solvable.  We have two options as I see it,
>>> either have to build it like upstream does, meaning one giant source
>>> package that we update and reupload for any small fix, even a tiny
>>> security fix.  Or do what we are doing: break up the packages mostly
>>> along the lines of the upstream git repos so that we can do security
>>> fixes without re-uploading the whole giant thing.
>>>
>>> We're dealing with libraries that have no stable API, neither source nor
>>> binary.  A bugfix release can change a header that lots of things are
>>> built against.
>>>
>>> This is not something we have done rashly, we've discussed this at
>>> length over a couple years.  We're also on our 3rd architectural
>>> approach.  We've tried to avoid as much badness as we could, this is
>>> where we have gotten.
>>
>> I thought we were looking for the best technical solution. Of course a
>> bugfix release can change a header or some other things, agreed, but in
>> this specific case nothing has changed. How can this be a management
>> nightmare?
> 
> Sometimes the best technical solution is a choice between bad options.
> That's life.  To understand why, consider that we need to build all C
> code against libs and headers with the exact same version.  Some source
> packages have circular dependencies.  For more details, dig into the
> archive of this list.  There has been a lot of discussion on this topic,
> and its also on the wiki some.
> 

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.

>> If the students had asked on debian-mentors for sponsorship everyone
>> there would have pointed out the same.
>>
>> I would have welcomed it if we had found a better solution and indeed
>> your way of handling this was way too pushy.
> 
> We've been uploading packages like that for a year now, its nothing new.
>  I didn't know that you didn't know.

How could I when you are the one who uploaded the packages. This was the
first time when someone asked me to upload a new upstream version
without upstream changes. Some people would call that odd.

Sorry this is not what I would call a collaborative effort to solve an
issue. The freeze is months away and there would have been enough time
to talk about this. Don't count me in anymore.

Regards,

Markus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20160801/dc55ee10/attachment.sig>