Boost.Python: Build and Install with Python 2.4 and 2.5?
Hi, I'm part of the Debian Boost packaging team, seeking some guidance on how to build and install Boost.Python so that it is usable with all Python versions shipped in Debian. Debian currently ships Python 2.4 and 2.5. When reading the following, keep in mind that Boost.Python is not a Python extension but, rather, a library that eases writing an extension in C++. So it is necessary that the compiled libraries be visible to be linked with user-written C++ code. One idea is to use a user-config.jam file containing using python : 2.4 : /usr ; using python : 2.5 : /usr ; Then run jam twice bjam variant= ... bjam variant= ... python python=2.5 This produces pairs of library files such as bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a (and similar pairs for shared libraries and all other variants). The key item to note is that the two files have the same name. The python version, unlike the GCC version, is not embedded in the library name. So these files cannot both be installed into /usr/lib. The question, then, is how to distinguish them once installed? Should we: 1. Rename the resulting libraries to decorate them with the python version in addition to the gcc version? This could generate libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.a 2. Similar to above, but use bjam's --buildid option? This has the drawback that the build ID shows up differently than the GCC version decoration, e.g. libboost_python-gcc42-1_34_1-py24.a libboost_python-gcc42-1_34_1-py25.a 3. Put the libraries in different subdirectories, e.g. /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a 4. Put the default version directly in /usr/lib and the others in subdirectories, e.g. /usr/lib/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a The drawback to all these approaches is that client code has to be adjusted to build on Debian. Linking against Boost (for non-bjam projects) is already hard enough with the decorated library names that I fear making the situation worse. The attraction of #4 is that at least the variants for the default python version are found in a natural manner. This has some appeal to me, personally, but I worry that it is too easy to build an extension to python 2.5 and link in the wrong Boost.Python library. In contrast, the other options have the advantage that it forces the user to declare which version of Python is being used. I'd appreciate your thoughts. Have I overlooked a better solution? What are the other packagers of Boost.Python doing? In principle, it would be nice to have the Boost libraries named the same across distributions. Thanks, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?
Hi, Thanks to Steve, Bernd, and Josselin for ideas. On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote: > Decorate only the shared library names with the python versions, and retain > the current names for the .a files and .so symlinks - with two separate -dev > packages that conflict with one another? > > That still prevents anyone from packaging an extension that builds for both > python2.4 and python2.5 at once using Boost.Python, but I think it solves > all the other drawbacks of the other solutions you suggested. Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem. On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote: > Hi, > > Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit : > > 1. Rename the resulting libraries to decorate them with the python > > version in addition to the gcc version? This could generate > > > > libboost_python-py24-gcc42-1_34_1.a > > libboost_python-py25-gcc42-1_34_1.a > > I think this is fine. [ ... ] > The solution is to keep the names decorated with both python versions, > but to maintain a farm of symbolic links pointing to the current python > version. As Steve noted, you don???t need one for the runtime libs, but > for the .a and the .so symlink that are used at build time, this is > required. OK, both you and Bernd suggested rtupdate. Bernd even pointed me to a description of it [1]; thanks. Let me see if I understand your proposal. The idea is to create a single -dev package that contains the following in /usr/lib: libboost_python-py24-gcc42-1_34_1.so libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.so libboost_python-py25-gcc42-1_34_1.a The -dev package contains an rtupdate script to create the following symlinks (also in /usr/lib): libboost_python-gcc42-1_34_1.so libboost_python-gcc42-1_34_1.a Does that sound right? This has the advantage that a Python extension can be build and packaged for either or both supported Python versions, albeit at the cost of changing the link line. Code that just needs the default version can use the undecorated form in the link line. The disadvantage is that if you use the undecorated form, you're not quite sure what version of Boost.Python is linked in. -Steve [1] http://people.debian.org/~srivasta/manoj-policy/x673.html signature.asc Description: Digital signature
Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote: > Steve M. Robbins wrote: > > Hi, > > > > Thanks to Steve, Bernd, and Josselin for ideas. > > > > > > On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote: > > > >> Decorate only the shared library names with the python versions, and retain > >> the current names for the .a files and .so symlinks - with two separate > >> -dev > >> packages that conflict with one another? > >> > >> That still prevents anyone from packaging an extension that builds for both > >> python2.4 and python2.5 at once using Boost.Python, but I think it solves > >> all the other drawbacks of the other solutions you suggested. > > > > Indeed. Do you think this is a serious restriction? Given that > > Debian likes to package extensions for all python versions, I tend to > > think it will become a problem. > > extensions for different python installations don't conflict because > they end up in separate directories. The proposal above is that we provide a boost-python-2.4-dev and a boost-python-2.5-dev package that conflict with one another (because they would contain files of the same name). This prevents a source package from depending on both for a build, and therefore a source package for a Python extension cannot produce an extension for each Python version. -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Wed, Feb 27, 2008 at 08:43:43AM -0500, Stefan Seefeld wrote: > (I still don't see the problem: Source packages don't depend on binary > packages, only binary packages do. Source packages *do*, in fact, depend on binary packages. Each source package describes exactly the packages required to build the source; e.g. whether Qt3 libraries or X11 libraries are needed. These are called "build-time dependencies" or "build-deps" for short. > And if you package your extension module you are in control of what > python version(s) you build against, no ?) That's a true statement. Several extension modules will, in fact, build for both Python 2.4 and 2.5. Now imagine an extension module that uses Boost.Python. As mentioned, it must have the relevant build-deps. To support this, the relevant boost-python development packages must be co-installable (i.e. not conflict with each other). It's not yet clear to me whether this is an achievable goal, but it would be nice. Regards, -Steve signature.asc Description: Digital signature
Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote: > > on Sat Feb 23 2008, "Steve M. Robbins" wrote: [...] > > This produces pairs of library files such as > > > > bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a > > bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a > > > > (and similar pairs for shared libraries and all other variants). > > > > The key item to note is that the two files have the same name. The > > python version, unlike the GCC version, is not embedded in the library > > name. So these files cannot both be installed into /usr/lib. > > I don't know how such name gristing is generated in Boost.Build, but IMO > we should change the naming to account for the Python version. Perhaps. For the moment, I can get the desired effect using --buildid. > > The question, then, is how to distinguish them once installed? > > Should we: > > > > > > 1. Rename the resulting libraries to decorate them with the python > > version in addition to the gcc version? This could generate > > > > libboost_python-py24-gcc42-1_34_1.a > > libboost_python-py25-gcc42-1_34_1.a > > I'm not an expert in this area, but it's been my understanding that > simply renaming library files doesn't work for some reason. Partly true. I believe you can rename the static libs (.a files) at will. The problem lies in the shared libs. Subsequent to writing the above, I discovered that the two shared libraries (.so.*) have exactly the same SONAME, so renaming doesn't work for them. > > 2. Similar to above, but use bjam's --buildid option? This has the > > drawback that the build ID shows up differently than the GCC version > > decoration, e.g. > > > > libboost_python-gcc42-1_34_1-py24.a > > libboost_python-gcc42-1_34_1-py25.a > > Sounds more likely to work, even though it's ugly. Yes, this works because the --buildid is incorporated into the SONAMEs, thus distinguishing them. Using --buildid is therefore the *only* solution short of hacking the soname generation myself. > > I'd appreciate your thoughts. Have I overlooked a better solution? > > What are the other packagers of Boost.Python doing? > > Unfortunately, we don't tend to get a lot of interaction with packagers > around here, so we don't tend to know what they're doing. I think Boost > raises more packaging issues than most other libraries, so it would be > good to have more involvement from y'all. Actually, the only thing about Boost that causes grief to packagers is that the toolset name (e.g. "gcc42") is embedded in the library filename. I just wrote a response on Boost.Build outlining this in some detail [1]. Embedding the compiler version requires Debian to rebuild all the boost packages each time a compiler change is made. This is unnecessary when the compiler ABI is maintained (e.g 4.1 -> 4.2) and also unnecessary when the ABI is broken, as Debian has another mechanism to handle that. Note that rebuilding the boost packages has a huge ripple effect, so it is more than simply "unnecessary", it is a very large headache. The fact that Boost embeds the Boost version in the library name is cause for grief to client software authors. But this is unavoidable as long as Boost doesn't take care to maintain ABI across versions. Fortunately, there is a simple solution to this, which I touch on in my post [1]. Regards, -Steve [1] http://lists.boost.org/boost-build/2008/03/18565.php signature.asc Description: Digital signature
Boost.Python: providing libs for both Python 2.4 and 2.5.
Hello,
I wrote about three weeks ago [1] that I'm trying to get Boost's
Python extension helper library building with multiple Python
versions. Several very helpful suggestions were made, for which I am
grateful.
I have been plugging away, very slowly, ever since. I'm hoping to
upload it later today and I'd appreciate have some second opinions on
what I've done.
I settled on creating libraries with suffix "-py24" and "-py25" using
the available Boost mechanism of "--buildid" since that ensures the
SONAME also has "-py24" or "-py25". The shared library files thus
coexist peacefully.
For the link libraries, I chose to retain both the fully-decorated
forms including the "-pyXY" suffix, as well as create symlinks (with
no suffix) for those who just want the default python version. These
symlinks are maintained by an "rtupdate" script as suggested by a
couple of people.
Focusing only on the simpler, Debian-specific, library names,
the intent is that the following link libraries are availble:
libboost_python-py24.a -> libboost_python-gcc42-1_34_1-py24.a
libboost_python-py24.so -> libboost_python-gcc42-1_34_1-py24.so
libboost_python-py25.a -> libboost_python-gcc42-1_34_1-py25.a
libboost_python-py25.so -> libboost_python-gcc42-1_34_1-py25.so
libboost_python.a -> libboost_python-py24.a
libboost_python.so -> libboost_python-py24.so
The rtupdate script (attached) will replace the last two libraries
with
libboost_python.a -> libboost_python-py25.a
libboost_python.so -> libboost_python-py25.so
This allows extension builders to select either the default Python
version, or a specific version, without knowing the Boost
and GCC versions [2].
I'd appreciate any feedback on the above, and especially on what
follows.
I'd love some folks to look over the attached rtupdate script. My
understanding is that this gets run when the Python default version
changes. If so, I guess that a bug in the script will cause the
Python package install to fail. I'd like to avoid the hate mail
generated if that happened; so if you've got a moment, have a look at
the script.
I'd like to ask about intended behaviour if a bad action is supplied.
Or if an unsupported python version is given. I chose to exit with an
error message and status 1. Now I'm a little worried that will break
some Python installs and generate the hate mail. What's the
recommended behaviour here?
Note that my libboost-python-dev postinst script calls it
to populate the symlinks initially:
/usr/share/python/runtime.d/libboost-python-dev.rtupdate \
rtupdate none $(pyversions -d)
I also use it in the prerm to remove all the symlinks:
/usr/share/python/runtime.d/libboost-python-dev.rtupdate \
remove
Thanks,
-Steve
[1] http://lists.debian.org/debian-python/2008/02/msg00033.html
[2] http://lists.debian.org/debian-python/2008/02/msg00045.html
#! /bin/sh
#
# Update link-library symlinks after a Python default runtime change
set -e
version=1_34_1
die() {
echo "$@" >&2
exit 1
}
update_linklibs() {
py=$1
suf=$2
cd /usr/lib
for thread in "" -mt; do
for gcc in gcc41 gcc42; do
ln -s -f
libboost_python-${gcc}${thread}${debug}-${version}-${py}.${suf} \
libboost_python-${gcc}${thread}${debug}-${version}.${suf}
done
ln -s -f libboost_python${thread}${debug}-${py}.${suf} \
libboost_python${thread}${debug}.${suf}
done
}
remove_linklibs() {
suf=$1
cd /usr/lib
for thread in "" -mt; do
for gcc in gcc41 gcc42; do
rm -f libboost_python-${gcc}${thread}${debug}-${version}.${suf}
done
rm -f libboost_python${thread}${debug}.${suf}
done
}
rtupdate() {
case "$1" in
python2.4) py=py24 ;;
python2.5) py=py25 ;;
*) die $0 unknown python version $1 ;;
esac
update_linklibs $py a
update_linklibs $py so
}
remove() {
remove_linklibs a
remove_linklibs so
}
if [ "$1" = "-d" ]; then
debug=-d
shift
fi
action="$1"
shift
case "$action" in
pre-rtupdate) ;;
post-rtupdate) ;;
rtupdate) rtupdate $1 ;;
remove)remove ;;
*) die "$0 called with unknown argument '$action'" ;;
esac
signature.asc
Description: Digital signature
Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.
On Fri, Mar 21, 2008 at 03:59:30PM -0400, Aaron M. Ucko wrote: > I do, however, see a couple of concrete issues with your script: > > > if [ "$1" = "-d" ]; then > > debug=-d > > shift > > fi > > Shouldn't you fix that at build time à la $version? You noticed a complication I was avoiding. There are actually two packages that need an rtupdate script: libboost-python-dev, and libboost-dbg. The latter holds all the "debug" versions of the libraries, including the Boost.Python libraries. The only difference in names is that the debug libraries have "-d" in them. So I was avoiding two scripts by this parameterization. [I have subsequently done the parameterization slightly differently; consult the boost svn repo for details or wait for the upload in a few hours] > > rtupdate) rtupdate $1 ;; > > More critically, AFAICT you want to pass $2, not $1. Indeed. I had sent out the note before fully testing the script. How embarrassing. Thanks, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.
On Mon, Mar 24, 2008 at 05:52:47PM +, Dominic Hargreaves wrote: > However, it looks to be like the shlibs file needs updating. Yes, and thanks for the bug report. Upload is being prepared now. -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473973: libboost-python-dev: rdeps fails?to built - python packaging seems weird
For the debian-python readers just joining in: the recent modification of Boost to support multiple Python runtimes has some unintended consequences; see bug #473973. Below are some questions for your consideration. On Wed, Apr 02, 2008 at 06:11:34PM +0200, Sune Vuorela wrote: > If I ask specifically for -lboost_python-py24 or -lboost_python-py25 > or -lboost_python-mt-py24 or -lboost_python-py25, kdeedu seems to build > properly. If I just ask for one of the defaults (-lboost_python > or -lboost_python-mt it doesn't build) You might want to consider doing so; this allows you to be clear as to which version of python you support. Or, indeed, build support for both 2.4 and 2.5. > > Please let me know what sequence of package installs (and what version > > of libboost-python-dev) led to the situation of no symlinks. > > The sequence of installation described here leaves it without those symlinks: > > http://people.debian.org/~lucas/logs/2008/04/01/kdeedu_4%3A3.5.9-1_sid32.buildlog OK, so this is using libboost-python-dev 1.34.1-10, which has the bug previously mentioned: if you don't have python installed prior to installing libboost-python-dev, you don't get the symlinks. The sequence shown in the build log indicates that no python-dev package is installed at all. This is due to another change made to support multiple python runtimes. The libboost-python-dev package used to depend on python-dev. Now that it supports two runtimes, it doesn't make sense to depend on both. Arguably it could depend on the default, but what I did instead is weaken the dependencies to suggest. This breaks your build because the suggestions are not installed. So here are some questions, and I'd like to throw then out to the wisdom of debian-python, too. 1. When does the rtupdate script get run? I assumed it will be run upon first install of python so as to configure all the python-using packages previously installed. But that does not seem to be the case. Should it be? If not, how should I handle the situation where libboost-python-dev is installed/configured prior to python being installed? 2. Prior to supporting multiple runtimes, libboost-python-dev used to depend on python2.4-dev. Now it simply suggests python2.4-dev and python2.5-dev since users of this package may need any of the currently-supported Python development packages. It means that some (perhaps all) packages that build-depend on libboost-python-dev now have to add python2.4-dev to their own build-deps. Is that tenable? 3. Alternatively, shall I add back python2.4-dev as a dependency for libboost-python-dev? This "penalizes" in some sense those who just want Python 2.5, but not egregiously so. It also assumes we can sort out issue #1, I think, unless we can assume something about the install ordering of the two packages. 4. For a package that build-depends on libboost-python-dev, what is the recommended strategy: to hack the build config and use the -py24 and -py25 library variants, or to rely on the symlinks and having the correct Python installed? Naively, I'd expect the latter strategy for those who simply need to support the default Python version, and the former for those who support all Python runtimes. > kdeedu build doesn't fail by itself if it isn't found as it is only optional, > but we test afterwards if it is actually build. Testing afterwards is a wise move! Cheers, -Steve signature.asc Description: Digital signature
When is rtupdate run?
On Thu, Apr 03, 2008 at 03:03:11PM +0200, Josselin Mouette wrote: > On mer, 2008-04-02 at 12:04 -0500, Steve M. Robbins wrote: > > So here are some questions, and I'd like to throw then out to the > > wisdom of debian-python, too. > > > > 1. When does the rtupdate script get run? I assumed it will be run > > upon first install of python so as to configure all the python-using > > packages previously installed. But that does not seem to be the case. > > Should it be? If not, how should I handle the situation where > > libboost-python-dev is installed/configured prior to python being > > installed? > > You need to run it by hand in the postinst. Right: libboost-python-dev does run it by hand in the postinst. In fact, so does the package libboost-dbg, which provides debug versions of all the Boost libs. However there is no reason for libboost-dbg to depend on python. This means I can't count on pyversions being available, so it is possible to install libboost-dbg without having the symlinks created. I was hoping is that if python is subsequently installed, that python itself would run the rtupdate scripts. This doesn't seem to be the case. Should it be? If not, how should I handle the situation where libboost-dbg is installed/configured prior to python being installed? To be concrete: if I install python, then libboost-dbg, I get the proper symlinks created by the libboost-dbg postinst invocation of the rtupdate script. However, if I install first libboost-dbg then python, the symlinks are not created. But I think they ought to be. Thanks, -Steve P.S. As you and Sune suggested, I'll change libboost-python-dev to depend on python-dev. signature.asc Description: Digital signature
Re: When is rtupdate run?
On Fri, Apr 04, 2008 at 10:29:37PM +0200, Josselin Mouette wrote: > On ven, 2008-04-04 at 10:48 -0500, Steve M. Robbins wrote: > > I was hoping is that if python is subsequently installed, that python > > itself would run the rtupdate scripts. This doesn't seem to be the > > case. Should it be? If not, how should I handle the situation where > > libboost-dbg is installed/configured prior to python being installed? > > It seems indeed like a good idea to run them when python is first > installed, so that is clearly a limitation of the current > python-defaults rtupdate mechanism. > > On the other hand, [...] Without getting bogged down in the precise details of my situation, the use case is simply this: a package that provides optional Python support may have an rtupdate script that is called by its postinst using "pyversions" to find the default runtime version. Since the Python support is optional, the package does not depend on python. In this case, its postinst script must skip the rtupdate if python is not available. When Python is subsequently installed, the rtupdate scripts of all previously-installed packages should be run. Sound reasonable? Shall I file a bug to this effect? On python? > On the other hand, I???m not sure such symbolic links are necessary for > debugging libraries; at least they are not for usual libraries. The debug library names all have the same -py24 and -py25 decoration as the non-debug ones found in libboost-python-dev. The symlinks are to support linking with the default Python runtime. This may not be "usual", but how else do you deal with a library supporting two Python runtimes? -Steve signature.asc Description: Digital signature
Re: When is rtupdate run?
On Sat, Apr 05, 2008 at 02:23:21AM +0200, Josselin Mouette wrote: > On ven, 2008-04-04 at 19:08 -0500, Steve M. Robbins wrote: > > > On the other hand, I???m not sure such symbolic links are necessary for > > > debugging libraries; at least they are not for usual libraries. > > > > The debug library names all have the same -py24 and -py25 decoration > > as the non-debug ones found in libboost-python-dev. The symlinks are > > to support linking with the default Python runtime. This may not be > > "usual", but how else do you deal with a library supporting two Python > > runtimes? > > This is all good for regular libraries, but as they are decorated, the > debuglink information added by dh_strip should point to the decorated > debugging library location, so you shouldn???t need the undecorated > symbolic link for the debugging libraries. Ah, now I see your confusion. For a "standard" library, you're perfectly right. The -dbg library has the same SONAME as the non-debug version. Boost is different: they decorate the debug library name (and SONAME) with an extra "-d". So the debug versions do need the default runtime symlinks. Cheers, -Steve signature.asc Description: Digital signature
Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote: > > on Thu Mar 13 2008, "Steve M. Robbins" wrote: > > > Actually, the only thing about Boost that causes grief to packagers is > > that the toolset name (e.g. "gcc42") is embedded in the library > > filename. I just wrote a response on Boost.Build outlining this in > > some detail [1]. Embedding the compiler version requires Debian to > > rebuild all the boost packages each time a compiler change is made. > > This is unnecessary when the compiler ABI is maintained (e.g 4.1 -> > > 4.2) and also unnecessary when the ABI is broken, as Debian has > > another mechanism to handle that. Note that rebuilding the boost > > packages has a huge ripple effect, so it is more than simply > > "unnecessary", it is a very large headache. > > I'm not sure that's the end of the story. One reason we embed the > compiler name in the library name is that version-specific workarounds > often show up in header files. The result is that when compiled against > gcc-4.2, client code will effectively see different header contents than > the precompiled boost library that was built with gcc-4.1 did. Interesting. I didn't know that. Debian's "unstable" distribution has been using the same compiled Boost libraries with a mix of GCC 4.1 and 4.2 since December. GCC 4.3 is being added to the mix, too. I should grep the boost headers for BOOST_WORKAROUND to see what differences might arise. > I think we'd need to work out a discipline of avoiding > BOOST_WORKAROUND code in headers that distinguishes compiler minor > versions. I'm not very confident that I've thought that issue > through completely... is it that simple? If possible, that would be nice from a library distributor's point of view. > > The fact that Boost embeds the Boost version in the library name is > > cause for grief to client software authors. But this is unavoidable > > as long as Boost doesn't take care to maintain ABI across versions. > > Fortunately, there is a simple solution to this, which I touch on in > > my post [1]. > > This is just a change to bjam? Have you gotten any traction with that > idea? It turns out to be simpler than that. With a small tweak to boost's Jamroot file, I'm now generating libraries without the toolset and without the Boost version decorations. I will use this for the upcoming Boost 1.35.0 Debian packages. We had a long thread in Boost.Build about this idea [1]. I'm not sure I convinced anyone to my point of view. :-) We'll proceed with Debian-specific changes for the short term and see how it goes. Regards, -Steve [1] Thread starts at http://lists.boost.org/boost-build/2008/04/18835.php The shortest statement of Debian's position is http://lists.boost.org/boost-build/2008/04/18839.php (And please ignore http://lists.boost.org/boost-build/2008/04/18918.php as I've changed my mind again) signature.asc Description: Digital signature
Re: Bug#516766: insighttoolkit: generates incorrect package with python-support from experimental
On Mon, Feb 23, 2009 at 04:16:50PM +0100, Josselin Mouette wrote: > the insighttoolkit rules file contains the following: > > PYMODDIR = usr/share/python-support/$(pkg_python) > PYEXTDIR = usr/lib/python-support/$(pkg_python)/$(PYVERS) > ... > install/$(pkg_python):: > dh_install -p$(pkg_python) -XlibSwig > debian/tmp/usr/lib/InsightToolkit/*Python.so* $(PYEXTDIR) > dh_install -p$(pkg_python) > debian/tmp/usr/lib/InsightToolkit/libSwigRuntimePython.so* usr/lib > dh_install -p$(pkg_python) debian/tmp/usr/lib/InsightToolkit/python/* > $(PYMODDIR) > dh_install -p$(pkg_python) debian/tmp/usr/lib/InsightToolkit/*.py > $(PYMODDIR) > dh_pysupport -p$(pkg_python) > > With the upcoming version of python-support (currently in experimental), > the files installed in /usr/lib/python-support are ignored and the built > package is, as such, broken. > > You should install these packages to a standard place instead of adding > all this complexity. Then, dh_pysupport will pick them and do whatever > is fit. OK. I'm certainly in favour of avoiding complexity. However, I thought I was following the python policy [1] where B.1 says: When using python-support, you should install your modules to /usr/share/python-support/package rather than the standard Python directories. Where should I be installing the .py files? Where should I be installing associated .so files? Thanks, -Steve [1] http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html#s-pysupport signature.asc Description: Digital signature
python policy manual not reliable
On Sun, Mar 08, 2009 at 05:27:33AM +0100, Josselin Mouette wrote: > Le samedi 07 mars 2009 ? 22:17 -0600, Steve M. Robbins a ?crit : > > OK. I'm certainly in favour of avoiding complexity. However, I > > thought I was following the python policy [1] where B.1 says: > > This document is incorrect. Since it is basically unmaintained and > contains many similar mistakes, you should especially not rely on it. Thanks, that's good to know. The document does look authoritative to the casual observer, however. Maybe we could get it removed until such time as it gets updated. WWW team: how does one go about getting http://www.debian.org/doc/packaging-manuals/python-policy/ removed? Thanks, -Steve signature.asc Description: Digital signature
SONAME for python modules is bad?
Hi, Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a python module is wrong, with reference to an oblique comment from Josselin Mouette [1]. Is this true? What is the rationale for not versioning these shared objects? Is there any "more official" document that mandates this? For example, the python policy? Thanks, -Steve [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378049#25 signature.asc Description: Digital signature
Re: SONAME for python modules is bad?
Hi,
A cc is appreciated as I don't subscribe to debian-python.
On Fri, Jul 24, 2009 at 03:49:16PM +0200, Mathieu Malaterre wrote:
> On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbins wrote:
> > Hi,
> >
> > Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a
> > python module is wrong, with reference to an oblique comment from
> > Josselin Mouette [1].
> >
> > Is this true? ?What is the rationale for not versioning these shared
> > objects?
Chow Loong Jin responded noting that Python modules are loaded
using dlopen or similar, and not by the runtime linker. He concludes
that this implies the normal shared object versioning is not required.
I don't quite follow that logic. I guess that conventionally a module
named "fooextension.so" is loaded; i.e. without a version. However,
one could, in principle, dlopen("fooextension.so.3") if one wanted
multiple versions of fooextension to coexist. Is it simply the case
that this need has not (yet?) arisen in practice?
In any event, if convention dictates that modules are not versioned,
that's fine with me. My next question is then: does it bother people
if ITK installs versioned shared objects *in addition to* the simple
".so" link that is used by the python code? It does this currently,
just because the build process treats all shared objects (modules and
libraries) identically. Is it worth while to change this or can we
just leave it alone?
> > Is there any "more official" document that mandates this? ?For
> > example, the python policy?
>
> This issue was raised by Denis Barbier. [...]
> It would be extremely nice too if all wrap language would adopt the
> same convention.
That would be nice.
Personally, I'd settle for each language having a clear policy written
down (in a location that I can easily find) so that I don't have to
guess. ;-)
Regards,
-Steve
signature.asc
Description: Digital signature
Re: SONAME for python modules is bad?
On Fri, Jul 24, 2009 at 07:13:19PM +0100, Max Bowsher wrote: > IMO it's potentially misleading clutter, but it doesn't harm anything, > so I'd consider it something that ought to be fixed, but very much low > priority. Agreed. Thanks, -Steve signature.asc Description: Digital signature
Re: Bug#595786: libboost-python-dev: Boost Python should also be compiled against Python3
On Mon, Sep 06, 2010 at 12:22:07PM -0400, Andreas Kloeckner wrote: > I very much appreciate that you already compile Boost Python against > Python 2.5 and 2.6. Since upstream already also supports Python3, it > would be nice to also compile against whatever the currently supported > version of Python3 is (3.1 as of this writing). I agree. Unfortunately, when I tried building Boost 1.44 (just uploaded to experimental), it failed to build Boost.MPI. I posted the build failure to the Boost list [1] but no response yet. I'd appreciate help in tracking down the problem. You can find the Debian package sources in svn [2]. The following patch adds support for Python 3.1. Thanks, -Steve [1] http://lists.boost.org/Archives/boost/2010/09/170659.php [2] svn://svn.debian.org/svn/pkg-boost/boost/trunk Index: debian/control === --- debian/control (revision 14598) +++ debian/control (working copy) @@ -4,9 +4,10 @@ Priority: optional Maintainer: Debian Boost Team Uploaders: Steve M. Robbins , Domenico Andreoli -Build-Depends: debhelper (>= 7), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu-dev, python-all-dev, python-support (>= 0.6), mpi-default-dev -Build-Conflicts: boost-build, libopenmpi-dev (= 1.3.2-2) +Build-Depends: debhelper (>= 7), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu-dev, python-all-dev, python3-all-dev (>= 3.1), python-support (>= 0.6), mpi-default-dev +Build-Conflicts: libopenmpi-dev (= 1.3.2-2) XS-Python-Version: >= 2.4 +XS-Python3-Version: >= 3.0 Vcs-Browser: http://svn.debian.org/wsvn/pkg-boost/boost/trunk/ Vcs-Svn: svn://svn.debian.org/svn/pkg-boost/boost/trunk Standards-Version: 3.8.3 Index: debian/rules === --- debian/rules(revision 14599) +++ debian/rules(working copy) @@ -13,7 +13,7 @@ SOVERSION = 1.44.0 SHLIBS_VERSION = (>= 1.44.0-1) -pyversions = $(shell pyversions -rv) +pyversions = $(shell pyversions -rv) 3.1 # Boost libraries for which we want separate packages boost_libs := date-time filesystem graph-parallel graph iostreams math \ signature.asc Description: Digital signature
Python 3.2: convert convert PyObject* to PyUnicodeObject*?
Hi,
Boost 1.46.1 fails to build with Python 3.2 on linux (Debian). The
build fails with:
error: cannot convert -F?PyObject*? to ?PyUnicodeObject*? for argument ?1? to
?Py_ssize_t PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)?-A
at this code:
static std::wstring extract(PyObject* intermediate)
{
std::wstring result(::PyObject_Length(intermediate), L' ');
if (!result.empty())
{
int err = PyUnicode_AsWideChar(
intermediate
, &result[0]
, result.size());
if (err == -1)
throw_error_already_set();
}
return result;
}
Is there an easy fix?
Thanks,
-Steve
signature.asc
Description: Digital signature
Will rtupdate be used for python 2 --> python 3 transition?
Hello, The Debian Python Policy documents [1] the rtupdate script for dealing with default runtime changes. Is this documentation still valid? Will rtupdate be used when the default runtime changes to python 3 or later? Thanks, -Steve [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-runtimes_hooks signature.asc Description: This is a digitally signed message part.
Re: Will rtupdate be used for python 2 --> python 3 transition?
Hi, On October 29, 2013 09:49:53 AM Dmitrijs Ledkovs wrote: > python3.X series and python2.X series are two distinct languages > (incompatible API and ABI changes), and it has been decided to keep > both alive as independent implementations. > thus "/usr/bin/python" will always point to a python2.X > implementation, Is there any documentation of this decision? The PEP you reference > http://www.python.org/dev/peps/pep-0394/ is much less firm on this matter: *Future Changes to this Recommendation[1]* It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2. [1] http://www.python.org/dev/peps/pep-0394/#id14 Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Re: pyvtk: deprecation of python-support
On Wed, May 20, 2015 at 06:36:33PM +0200, dktrkr...@debian.org wrote: > Source: pyvtk > Version: 0.4.74-3 I haven't uploaded pyvtk since 2011. So while looking to fix this bug, I went looking for the most recent sources and found out that you can easily get pyvtk via pip. Since I don't use pyvtk anymore, it occurred to me to simply remove the .deb package and assume folks will use pip. What does debian-python say to that idea? Thanks, -Steve signature.asc Description: Digital signature
Re: Bug#786247: pyvtk: deprecation of python-support
On August 8, 2015 10:13:04 AM Piotr Ożarowski wrote: > [Steve M. Robbins, 2015-08-08] > > > I went looking for the most recent sources and found out that you > > > > can easily get pyvtk via pip. > > `sudo pip install ...` is the same as `rm -rf /` to me. I see. > Please don't suggest it! In my defense: I did not say you need to use "sudo". All you need (at least for pyvtk) is privilege to write into /usr/local, so it is more like "rm -rf /usr/local" ... still damaging but not as dramatic. :-) > If you don't want to maintain it, report RFA or O > bug or simply remove it from the archive, but never ever suggest users > to use pip for installing system libs/apps. I had to clean after these > tools way too many times! pip is great when used inside virtualenv or > tools like this, but should return "please use rpm/dpkg" whenever > invoked as root, period! Thanks. I had read Paul Tagliamonte's essay [1] and wondered whether I'd get this kind of response. :-) I won't wade into the debate. [1] http://notes.pault.ag/debian-python/ Best, -Steve signature.asc Description: This is a digitally signed message part.
pure python and postinst
Howdy, I've just finished my first attempt at packaging a python module. This module (people.debian.org/~smr/pyvtk) is purely python. I followed the "python policy" outlined in /usr/share/doc/python, and also looked at a couple of example packages. One thing I noticed in the packages (that isn't covered in the policy) is the practice of deleting the ".pyc" files in debian/rules, and then running "compileall.py" in the postinst. Would someone comment on this? Is it a requirement -- is it a bug to include the compiled python files in the .deb? Thanks, -Steve P.S. Other comments on my package (url above) greatly appreciated!
breaks other packages
severity 170711 critical thanks Hi, I ran into coredumps when using python-vtk, see bug #170498. I believe the coredumps are due to python moving from tcl/tk 8.3 to tcl/tk 8.4. Other python extenion modules are still built with the older tcl/tk, so you end up with both 8.3 and 8.4 loaded. I think this bug should be release-critical to hold up the move to "testing" until all the modules are in sync, right? -Steve
Re: pure python and postinst
On Wed, Apr 02, 2003 at 09:20:22AM +1000, Donovan Baarda wrote: > G'day, > > just going through my old inbox messages that didn't seem to be replied > to; > > On Mon, 2002-11-18 at 13:11, Steve M. Robbins wrote: Well, thanks! I had forgotten about this. I'm no longer sure what prompted my question. Perhaps it was idle curiousity ... > > I've just finished my first attempt at packaging a python module. > > This module (people.debian.org/~smr/pyvtk) is purely python. > > > > I followed the "python policy" outlined in /usr/share/doc/python, and > > also looked at a couple of example packages. > > > > One thing I noticed in the packages (that isn't covered in the policy) ... or maybe I was wondering why this common practice isn't covered in the python packaging document that I was using at the time. A summary of this little thread would make a nice addition to the policy if it is not yet in there. -S
Python Modules Packaging Team
Howdy, This sounds like a good initiative. I'd like to add the python-modules-team as uploader of pyvtk, a package I maintain. Do I understand correctly that this implies I should put pyvtk into the alioth subversion repository? If so: sign up user 'smr' for this. Cheers, -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
