[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#904316: transition: boost-defaults



On Sun, 23 Sep 2018 at 08:38, Adrian Bunk <bunk@debian.org> wrote:
>
> On Wed, Sep 19, 2018 at 12:45:12PM +0200, Dimitri John Ledkov wrote:
> > On Sun, 16 Sep 2018 at 11:16, Niels Thykier <niels@thykier.net> wrote:
> >...
> > > Hi,
> > >
> > > I noticed at least 13 packages that have boost-related changes in an
> > > Ubuntu diff (and I certainly have *not* checked all packages in the
> > > boost transition tracker; I only looked at dep level 3).
> > >
> > >  * libcutl
> > >  * lvtk
> > >  * minieigen
> > >  * opengm (removes binary packages)
> > >  * performous (moves to boost1.65)
> > >  * pyexiv2
> > >  * pytango
> > >  * shark (reduces test precision)
> > >  * tagpy
> > >  * vcmi (moves to boost1.65)
> > >  * anytun
> > >  * aptitude
> > >  * freeture
> > >
> > > Can you please provide a full list of packages that will break with the
> > > new boost default?  How will Debian handle the packages that Ubuntu
> >
> > I do not have a full list. These do not break on runtime in general
> > (apart from a very small subset of things which dlopen/link
> > incompatible plugins), since old boost is provided and is
> > co-installable. They may start to FTBFS.
>
> If you want to do the normal build-testing before the transition,
> it would be helpful to have updated boost-defaults in experimental.
>

Largely rebuilds in Ubuntu have been sufficient to identify and fix
the bulk of boost transition issues
http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.67.html

After the initial rounds of NMUs I typically work off the Debian
transition tracker to complete transition / files FTBFS bugs / NMU
patches.

I can prepare the boost-defaults upload into experimental, but I'd
rather have this transition approved and boost-defaults uploaded into
unstable.

> >...
> > those will stick on boost1.62. thus the option for those would be to
> > change build-dep to libboost1.62-all-dev.
>
> Changing build dependencies to 1.62 only makes sense if this version
> will be shipped in buster.
>

This request is for transitioning boost-defaults from 1.62 to 1.67,
without removal of 1.62.

> >...
> > The longer this transition is delayed the worse it gets. Thus already
> > default boost is 5 major releases behind.
>
> What is the version planned to be shipped in buster?
>

Source packages: boost1.67 boost1.62 boost-defaults

> 1.68 is already released, and 1.69 will be released in December.
>

Neither of which are packaged yet.

> IMHO doing 1.62 -> 1.67 -> 1.68 would not make sense at this point.
>
> Better options would be:
> 1.62 -> 1.68 -> 1.69
> 1.62 -> 1.68
> 1.62 -> 1.67 -> 1.69
>

Cool, are you signing up to package 1.68 & 1.69 then? - my reading of
your email seems to imply, that packaging of 1.68/1.69 is a given when
it is not.

Cause at the moment we have only 1.67 done, which was extremely hard
to complete in order to comply with copyright requirements.

> The critical question here is whether there will be a transition to 1.69
> before the transition freeze (January 12th).
>

At the moment there are no volunteers who can commit to packaging
1.68/1.69 and specifically updating the copyright file. Unless you can
volunteer to do that.

I have no intentions on packaging 1.68 or 1.69 in Ubuntu for the 19.04
release at the moment. Thus most likely can look into further boost
new upstream packaging in a years time only probably.

-- 
Regards,

Dimitri.


Reply to: