Le mercredi 06 mai 2009 à 18:14 +0100, Neil Williams a écrit : > It did strike me as unusual when working from a basis of autotools and > C/C++ packages. If the -dbg package is more than just debugging > symbols, should those other parts be in the -dev and leave the > debugging symbols alone? Is that practical with python-all-dbg?
python-gtk2-dbg contains two things:
* detached debugging symbols for the regular modules
* modules suitable for the python2.X-dbg interpreters
The detached symbols are often enough if a bug happens in GTK+ or
directly in the override, but if you really want to debug the Python
modules themselves with a look at the interaction between C and Python
code, you need the python-dbg interpreter, with an entirely different
set of modules.
> I'm assuming from your reply that it's only when building extensions to
> python itself that you'd need python-all-dbg rather than for "ordinary"
> python builds like GUI python applications? (I don't know enough about
> python builds.) Is python-gtk2 a different interpreter?
You only need python-all-dbg when building C extensions for the
python2.X-dbg interpreter. python-gtk2 is not an interpreter in itself,
it is a set of C extensions for the python2.X interpreters, while
python-gtk2-dbg is the same set of extensions for the python2.X-dbg
interpreters.
For developing pure Python applications, you only need python and
python-gtk2. Only when developing C extensions to Python will you need
python-all-dev, and when developing C extensions to Python deriving from
the GTK+ classes will you need python-gtk2-dev.
(Sorry for the repetitions, but there doesn’t seem to be a
straightforward way to explain that.)
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
signature.asc
Description: Ceci est une partie de message numériquement signée
