Bug#904316: transition: boost-defaults
On Sun, 16 Sep 2018 at 11:16, Niels Thykier <niels@thykier.net> wrote:
>
> Dimitri John Ledkov:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian.org@packages.debian.org
> > Usertags: transition
> >
> > This is a transition request to upgrade boost defaults from 1.62 to
> > 1.67. Whilst 1.65.1 never made it into Debian, it has in Ubuntu and
> > the transition from 1.62->1.65.1 has been completed there. The
> > transition from 1.65.1 -> 1.67 is ongoing, with almost all core
> > packages transitioned already.
> >
> > The most common issues are general fixes due to rebuilding with newer
> > gcc toolchain, removal of std::tr1::* provided namespace (e.g. instead
> > of std::tr1::regex use either boost::regex or std::regex), and change
> > in naming convention of boost_python sonames (which is now
> > multi-python aware upstream, and debian now matching it).
> >
> > Majority of fixes are already present in upstream releases, Ubuntu
> > uploads, or are trivial in nature.
> >
> > I would like to upload boost-defaults, to kick of transition and work
> > towards removing boost1.62 from testing before relese.
> >
> > Ben file:
> >
> > title = "boost-defaults";
> > is_affected = .depends ~ /libboost[a-z-.]*1\.6[0123457]/;
> > is_good = .depends ~ /libboost[a-z-.]*1\.67/;
> > is_bad = .depends ~ /libboost[a-z-.]*1\.6[012345]/;
> >
> >
> >
>
> 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.
Most of the patches are not multi-boost compatible, ie. they only
build with old or new boost, not either. (cannot upload those patches
into debian now, to make packages bin-nmuable for boost1.62 -> 1.67
jump)
> migrated to boost1.65 and left at that version (e.g. performous and vcmi
> above)? AFAICT, Debian does not have a boost1.65 to migrate too.
>
those will stick on boost1.62. thus the option for those would be to
change build-dep to libboost1.62-all-dev.
The fact that Debian has so far chosen to reject boost1.65 has
significantly dampened the patch flow from ubuntu to debian, as for
many releases our FTBFS fixes were not applicable as is, nor
reproducible in debian.
The longer this transition is delayed the worse it gets. Thus already
default boost is 5 major releases behind.
--
Regards,
Dimitri.
Reply to: