12:07 p.m.
I was recently surprised that `dnf install boost` brings in python2.
It is like that because boost brings in bost-python and that is python2
ATM. I've reported it as a bug, because it bugs me :)
https://bugzilla.redhat.com/show_bug.cgi?id=1569483
However Jonathan Wakely (the boost maintainer) says this needs broader
audience.
So I'm asking here on devel:
Should the 'boost' metapackage install boost-python at all? If so, what
versions?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:42 p.m.
New subject: Should boost package install boost-python2 / boost-python3 /
both or none?
On 19/04/18 19:07 +0200, Miro Hrončok wrote:
I was recently surprised that `dnf install boost` brings in python2.
It is like that because boost brings in bost-python and that is
python2 ATM. I've reported it as a bug, because it bugs me :)
https://bugzilla.redhat.com/show_bug.cgi?id=1569483
However Jonathan Wakely (the boost maintainer) says this needs broader
audience.
So I'm asking here on devel:
Should the 'boost' metapackage install boost-python at all? If so,
what versions?
I think my preference would be to simply remove boost-python and
boost-numpy from the 'boost' package, and remove their headers and
shared library symlinks from the boost-devel package.
This would make the Boost.Python packaging consistent for python2 and
python3: you'd always need to explicitly choose which you want.
This will mean if you want to install Boost.Python you won't be able
to just use 'dnf install boost' you'll need to also install
boost-python2 or boost-python3 explicitly.
If you want to compile code using Boost.Python it won't be enough to
install boost-devel, you'll need to choose either boost-python2-devel
or boost-python3-devel.
The alternative would be to switch the "default" to be the python3
packages (and split some things out into new packages, e.g. currently
boost-mpich-devel installs %{_libdir}/mpich/lib/libboost_mpi_python.so
but this should really be in a separate boost-mpich-python2-devel
package).
1:02 p.m.
New subject: Should boost package install boost-python2 / boost-python3 /
both or none?
On 19/04/18 18:42 +0100, Jonathan Wakely wrote:
On 19/04/18 19:07 +0200, Miro Hrončok wrote:
>I was recently surprised that `dnf install boost` brings in python2.
>
>It is like that because boost brings in bost-python and that is
>python2 ATM. I've reported it as a bug, because it bugs me :)
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1569483
>
>However Jonathan Wakely (the boost maintainer) says this needs
>broader audience.
>
>So I'm asking here on devel:
>
>Should the 'boost' metapackage install boost-python at all? If so,
>what versions?
I think my preference would be to simply remove boost-python and
boost-numpy from the 'boost' package, and remove their headers and
shared library symlinks from the boost-devel package.
This would make the Boost.Python packaging consistent for python2 and
python3: you'd always need to explicitly choose which you want.
This will mean if you want to install Boost.Python you won't be able
to just use 'dnf install boost' you'll need to also install
boost-python2 or boost-python3 explicitly.
If you want to compile code using Boost.Python it won't be enough to
install boost-devel, you'll need to choose either boost-python2-devel
or boost-python3-devel.
The alternative would be to switch the "default" to be the python3
packages (and split some things out into new packages, e.g. currently
boost-mpich-devel installs %{_libdir}/mpich/lib/libboost_mpi_python.so
but this should really be in a separate boost-mpich-python2-devel
package).
I forgot to mention that this will break any packages using
Boost.Python which currently just have BR: boost-devel but that's
arguably a good thing anyway. It will be easy to fix them, and we will
have to make an explicit decision whether they should really be
using the python2 version, or should use boost-python3 instead.
1:06 p.m.
New subject: Should boost package install boost-python2 / boost-python3 / both
or none?
On Thu, Apr 19, 2018 at 1:02 PM, Jonathan Wakely <jwakely(a)fedoraproject.org>
wrote:
I forgot to mention that this will break any packages using
Boost.Python which currently just have BR: boost-devel but that's
arguably a good thing anyway. It will be easy to fix them, and we will
have to make an explicit decision whether they should really be
using the python2 version, or should use boost-python3 instead.
+1
Richard
4:47 a.m.
New subject: Should boost package install boost-python2 / boost-python3 / both
or none?
On Thu, 19 Apr 2018, 19:02 Jonathan Wakely, <jwakely(a)fedoraproject.org>
wrote:
On 19/04/18 18:42 +0100, Jonathan Wakely wrote:
>On 19/04/18 19:07 +0200, Miro Hrončok wrote:
>>I was recently surprised that `dnf install boost` brings in python2.
>>
>>It is like that because boost brings in bost-python and that is
>>python2 ATM. I've reported it as a bug, because it bugs me :)
>>
>>https://bugzilla.redhat.com/show_bug.cgi?id=1569483
>>
>>However Jonathan Wakely (the boost maintainer) says this needs
>>broader audience.
>>
>>So I'm asking here on devel:
>>
>>Should the 'boost' metapackage install boost-python at all? If so,
>>what versions?
>
>I think my preference would be to simply remove boost-python and
>boost-numpy from the 'boost' package, and remove their headers and
>shared library symlinks from the boost-devel package.
>
>This would make the Boost.Python packaging consistent for python2 and
>python3: you'd always need to explicitly choose which you want.
>
>This will mean if you want to install Boost.Python you won't be able
>to just use 'dnf install boost' you'll need to also install
>boost-python2 or boost-python3 explicitly.
>
>If you want to compile code using Boost.Python it won't be enough to
>install boost-devel, you'll need to choose either boost-python2-devel
>or boost-python3-devel.
>
>The alternative would be to switch the "default" to be the python3
>packages (and split some things out into new packages, e.g. currently
>boost-mpich-devel installs %{_libdir}/mpich/lib/libboost_mpi_python.so
>but this should really be in a separate boost-mpich-python2-devel
>package).
I forgot to mention that this will break any packages using
Boost.Python which currently just have BR: boost-devel but that's
arguably a good thing anyway. It will be easy to fix them, and we will
have to make an explicit decision whether they should really be
using the python2 version, or should use boost-python3 instead.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Honestly this sounds like the best idea for the path to take... especially
with the looming removal of python2 in F30 anyway.
5:44 p.m.
New subject: Should boost package install boost-python2 / boost-python3 /
both or none?
On 19/04/18 19:02 +0100, Jonathan Wakely wrote:
On 19/04/18 18:42 +0100, Jonathan Wakely wrote:
>On 19/04/18 19:07 +0200, Miro Hrončok wrote:
>>I was recently surprised that `dnf install boost` brings in python2.
>>
>>It is like that because boost brings in bost-python and that is
>>python2 ATM. I've reported it as a bug, because it bugs me :)
>>
>>https://bugzilla.redhat.com/show_bug.cgi?id=1569483
>>
>>However Jonathan Wakely (the boost maintainer) says this needs
>>broader audience.
>>
>>So I'm asking here on devel:
>>
>>Should the 'boost' metapackage install boost-python at all? If so,
>>what versions?
>
>I think my preference would be to simply remove boost-python and
>boost-numpy from the 'boost' package, and remove their headers and
>shared library symlinks from the boost-devel package.
>
>This would make the Boost.Python packaging consistent for python2 and
>python3: you'd always need to explicitly choose which you want.
>
>This will mean if you want to install Boost.Python you won't be able
>to just use 'dnf install boost' you'll need to also install
>boost-python2 or boost-python3 explicitly.
>
>If you want to compile code using Boost.Python it won't be enough to
>install boost-devel, you'll need to choose either boost-python2-devel
>or boost-python3-devel.
>
>The alternative would be to switch the "default" to be the python3
>packages (and split some things out into new packages, e.g. currently
>boost-mpich-devel installs %{_libdir}/mpich/lib/libboost_mpi_python.so
>but this should really be in a separate boost-mpich-python2-devel
>package).
I forgot to mention that this will break any packages using
Boost.Python which currently just have BR: boost-devel but that's
arguably a good thing anyway. It will be easy to fix them, and we will
have to make an explicit decision whether they should really be
using the python2 version, or should use boost-python3 instead.
I am about to push these changes to dist-git and build boost-1.66.0-6
for rawhide.
It looks like the packages below use boost-python and so might need
their spec files adjusting to add BuildRequires: boost-python2-devel
$ dnf repoquery --releasever=rawhide --archlist=x86_64 --disablerepo='*'
--enablerepo=updates --enablerepo=fedora --whatrequires
'libboost_python.so.1.66.0()(64bit)'
enabling updates-debuginfo repository
enabling fedora-debuginfo repository
Last metadata expiration check: 0:00:15 ago on Thu 26 Apr 2018 23:36:30 BST.
Singular-libs-0:4.1.0p3-8.fc28.x86_64
airinv-0:1.00.1-18.fc28.x86_64
airrac-0:1.00.1-15.fc28.x86_64
airtsp-0:1.01.3-8.fc28.x86_64
avogadro-libs-0:1.2.0-15.fc28.x86_64
boost-devel-0:1.66.0-5.fc29.x86_64
boost-mpich-python-0:1.66.0-5.fc29.x86_64
boost-numpy-0:1.66.0-5.fc29.x86_64
boost-openmpi-python-0:1.66.0-5.fc29.x86_64
condor-0:8.6.10-1.fc29.x86_64
freecad-1:0.17-0.1.pre.fc29.x86_64
freeorion-0:0.4.7.1-8.fc29.x86_64
k3d-0:0.8.0.6-14.fc28.x86_64
kig-0:18.04.0-1.fc29.x86_64
ledger-0:3.1.1-15.fc29.x86_64
openvdb-python2-0:5.0.0-2.fc29.x86_64
pyexiv2-0:0.3.2-33.fc28.x86_64
python2-botan-0:1.10.17-3.fc28.x86_64
python2-condor-0:8.6.10-1.fc29.x86_64
python2-csdiff-0:1.3.3-4.fc28.x86_64
python2-dlib-0:19.4-7.fc29.x86_64
python2-dmlite-0:1.10.2-1.fc29.x86_64
python2-gattlib-0:0.20150805-4.fc28.x86_64
python2-gfal2-0:1.9.3-6.fc28.x86_64
python2-hokuyoaist-0:3.0.2-22.fc28.x86_64
python2-ledger-0:3.1.1-15.fc29.x86_64
python2-libpst-0:0.6.71-7.fc28.x86_64
python2-lmiwbem-0:0.7.2-18.fc28.x86_64
python2-mapnik-0:0.1-33.20170614git1635afe.fc29.x86_64
python2-openimageio-0:1.8.10-1.fc29.x86_64
python2-osmium-0:2.14.0-1.fc29.x86_64
python2-trademgen-0:1.00.2-17.fc28.x86_64
python2-vigra-0:1.11.1-6.fc29.x86_64
python3-vigra-0:1.11.1-6.fc29.x86_64
rb_libtorrent-python2-0:1.1.7-1.fc29.x86_64
rmol-0:1.00.1-16.fc28.x86_64
sevmgr-0:1.00.2-16.fc28.x86_64
simcrs-0:1.01.1-15.fc28.x86_64
simfqt-0:1.00.1-15.fc28.x86_64
stdair-0:1.00.6-3.fc28.x86_64
trademgen-0:1.00.2-17.fc28.x86_64
travelccm-0:1.00.2-14.fc28.x86_64
vegastrike-0:0.5.1-32.r1.fc28.x86_64
The four boost-* packages are expected, and don't need changes.
My query might be wrong, because python3-vigra should not depend on
boost-python2, but I'll check all of them tomorrow.
2:08 p.m.
New subject: Should boost package install boost-python2 / boost-python3 /
both or none?
On 26/04/18 23:44 +0100, Jonathan Wakely wrote:
On 19/04/18 19:02 +0100, Jonathan Wakely wrote:
>I forgot to mention that this will break any packages using
>Boost.Python which currently just have BR: boost-devel but that's
>arguably a good thing anyway. It will be easy to fix them, and we will
>have to make an explicit decision whether they should really be
>using the python2 version, or should use boost-python3 instead.
I am about to push these changes to dist-git and build boost-1.66.0-6
for rawhide.
It looks like the packages below use boost-python and so might need
their spec files adjusting to add BuildRequires: boost-python2-devel
$ dnf repoquery --releasever=rawhide --archlist=x86_64 --disablerepo='*'
--enablerepo=updates --enablerepo=fedora --whatrequires
'libboost_python.so.1.66.0()(64bit)'
enabling updates-debuginfo repository
enabling fedora-debuginfo repository
Last metadata expiration check: 0:00:15 ago on Thu 26 Apr 2018 23:36:30 BST.
Singular-libs-0:4.1.0p3-8.fc28.x86_64
avogadro-libs-0:1.2.0-15.fc28.x86_64
condor-0:8.6.10-1.fc29.x86_64
freeorion-0:0.4.7.1-8.fc29.x86_64
k3d-0:0.8.0.6-14.fc28.x86_64
kig-0:18.04.0-1.fc29.x86_64
openvdb-python2-0:5.0.0-2.fc29.x86_64
pyexiv2-0:0.3.2-33.fc28.x86_64
python2-condor-0:8.6.10-1.fc29.x86_64
rb_libtorrent-python2-0:1.1.7-1.fc29.x86_64
vegastrike-0:0.5.1-32.r1.fc28.x86_64
The packages above are fixed now, by adding boost-python2-devel to
BuildRequires (and in one case Requires as well).
python2-vigra-0:1.11.1-6.fc29.x86_64
python3-vigra-0:1.11.1-6.fc29.x86_64
I've created a pull request for vigra.
freecad-1:0.17-0.1.pre.fc29.x86_64
This fails for an unrelated reason:
dos2unix: copying.lib: No such file or directory
Richard, should I push the fix to add boost-python2-devel anyway, or
do you want to do it?
ledger-0:3.1.1-15.fc29.x86_64
python2-ledger-0:3.1.1-15.fc29.x86_64
These are rebuilt but need doing again for ICU.
I'm still working through the rest:
>airinv-0:1.00.1-18.fc28.x86_64
>airrac-0:1.00.1-15.fc28.x86_64
>airtsp-0:1.01.3-8.fc28.x86_64
>python2-botan-0:1.10.17-3.fc28.x86_64
>python2-csdiff-0:1.3.3-4.fc28.x86_64
>python2-dlib-0:19.4-7.fc29.x86_64
>python2-dmlite-0:1.10.2-1.fc29.x86_64
>python2-gattlib-0:0.20150805-4.fc28.x86_64
>python2-gfal2-0:1.9.3-6.fc28.x86_64
>python2-hokuyoaist-0:3.0.2-22.fc28.x86_64
>python2-libpst-0:0.6.71-7.fc28.x86_64
>python2-lmiwbem-0:0.7.2-18.fc28.x86_64
>python2-mapnik-0:0.1-33.20170614git1635afe.fc29.x86_64
>python2-openimageio-0:1.8.10-1.fc29.x86_64
>python2-osmium-0:2.14.0-1.fc29.x86_64
>python2-trademgen-0:1.00.2-17.fc28.x86_64
>rmol-0:1.00.1-16.fc28.x86_64
>sevmgr-0:1.00.2-16.fc28.x86_64
>simcrs-0:1.01.1-15.fc28.x86_64
>simfqt-0:1.00.1-15.fc28.x86_64
>stdair-0:1.00.6-3.fc28.x86_64
>trademgen-0:1.00.2-17.fc28.x86_64
>travelccm-0:1.00.2-14.fc28.x86_64
2180
days inactive
2192
days old
6 comments
4 participants
participants (4)
-
James Hogarth -
Jonathan Wakely -
Miro Hrončok -
Richard Shaw