Bug#760343: transition: protobuf 2.6.0

[Emilio Pozuelo Monfort <pochu@debian.org>]

On 10/09/14 23:09, Robert Edmonds wrote:
> Emilio Pozuelo Monfort wrote:
>> My only concern here is that we hit problems like on the previous transitions,
>> this close to the freeze. But ia64 and sparc are no longer release architectures
>> and you tested both on amd64 and s390x, and the last time you did a good job in
>> fixing the regressions, so I'm confident you'll do the same now if any problem
>> arises (hopefully not). So go ahead and let me know when we're ready for the
>> binNMUs.
>>
>> Emilio
> 
> Thank you very much!  I will upload protobuf 2.6.0-3 to unstable soon.
> 
> It's true that we did see some annoying regressions in the last protobuf
> transition, but that was largely due to me trying to hack around
> upstream's lack of explicit support for some of our architectures (they
> had per-architecture assembly implementations with no generic fallback),
> which has been corrected in the latest release.  I'm also happy to
> report that upstream has fixed all of our portability issues in the most
> recent release and I was able to retire all of the Debian-specific
> portability patches.  So I'm hopeful this transition will be a bit
> smoother than the last one.
> 
> By the way, I notice on the transition tracker web page:
> 
>     https://release.debian.org/transitions/html/auto-protobuf.html
> 
> that the "affected" Ben expression is:
> 
>     .depends ~ /libprotobuf\-lite9|libprotobuf9|libprotoc9|libprotobuf\-lite8|libprotobuf8|libprotoc8/
> 
> I think this excludes packages whose source packages have a
> Build-Dependency on protobuf-compiler, but whose binary packages *don't*
> have a corresponding dependency on one of protobuf's library packages.
> Can you clarify whether those packages should be binNMU'd as well, or
> should the transition be limited strictly to the ABI transition of
> protobuf's library packages?  Looking at the difference between the
> auto-protobuf transition tracking page and the list of packages I
> generated with my Ben expression:
> 
>>> is_affected = .depends ~ /libprotobuf8|libprotobuf-lite8|libprotoc8/ | .depends ~ /libprotobuf9|libprotobuf-lite9|libprotoc9/ | .build-depends ~ /protobuf-compiler/;
> 
> The additionally affected packages seem to be:
> 
>     chromium-browser
>     closure-compiler
>     mapnik-vector-tile
>     meson
>     python-shogun
> 
> At least in the case of mapnik-vector-tile (which ships the output of
> running the protobuf compiler), which I examined more closely than the
> others, I am inclined to think that any package that runs the protobuf
> compiler during its build should be binNMU'd, otherwise FTBFS issues
> could go unnoticed until a new upload or a QA rebuild.  But maybe this
> is too aggressive.  Any advice?

I guess we could do those, better safe than sorry. However since they don't have
any dependencies on libproto*, they will probably migrate instantly. I'm not
sure that is the intended behaviour either.

I have scheduled the first round of binNMUs (all but protobuf-c, node-mapnik,
osmium and the 5 packages that don't have the dependencies).

Regards,
Emilio