ubuntu-phone team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

Hi Łukasz,

On Thu, Jul 16, 2015 at 08:13:28PM +0200, Łukasz 'sil2100' Zemczak wrote:
> W dniu 16.07.2015 o 09:26, Steve Langasek pisze:
> > The bugs are now marked critical, and there's good progress on a number of
> > them with merge proposals raised, but we need these to be fixed as soon as
> > possible; because once fixed, we will need to see which of these packages
> > fail to build with gcc 5.  There are already a number of packages failing to
> > build, which will need to be fixed up as shown in the silo ppa:

> >   https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages

> > And once the above packages have been adjusted not to use g++-4.9, we may
> > see a few more build failures.

> > We'll prepare a list of all failing packages shortly to discuss with the
> > responsible teams, but in the meantime if you want to get started on fixing
> > the build failures shown there, there's no time like the present!

> One thing we need to think about here is what changes do those touch
> projects require to become gcc-5 compatible. Most projects currently
> dual-land to vivid and wily and I suppose every lander would like that
> to stay this way - as branching to two trunks means trouble for both the
> developers and train operators. I wonder it it'll be possible to still
> keep that compatibility for everything.

Of course, we want dual landings to continue for components as long as
possible.  But for libraries that are undergoing ABI changes, being packaged
correctly means carrying differences in the packaging for the two releases. 
We currently plan to take a shortcut with the Ubuntu archive as a whole in
order to avoid bundling hundreds of package name changes together and to
avoid doing the transition ahead of (and differently from) Debian.  But for
packages going through the train that Canonical is upstream for, I don't
think we want to sacrifice correctness.  Not only does this increase the
risk of breaking reverse-dependencies of these libraries in wily if they're
overlooked, I think it also has implications for being able to assert
correctness of the SDK dependencies between releases.

So while those packages which only need to drop their g++-4.9
build-dependency should be fine to continue dual landings on, for packages
shipping shared librares I think realistically we are going to want two
branches.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

Attachment: signature.asc
Description: Digital signature