On 6/25/14, Matthias Klose <d...@debian.org> wrote: > Am 25.06.2014 02:51, schrieb Samuel Bronson: >> * Guarantee that GDB will pull in the "six" package appropriate for >> the Python it's built against (python-six or python3-six) > > this has nothing to do with 2/3. It is the responsibility of the package using > additional packages to declare these dependencies and/or suggestions. The > only > package I see using six is libreoffice, and this use is independent of the > python version.
The idea here is: * -gdb.py files should be 2/3 agnostic so that they work on *any* distribution, and with custom gdb builds using whichever Python series. * The "six" package is helpful in achieving that sort of thing * However, packages shipping -gdb.py files shouldn't be pulling in Python, much less "six", and in any case shouldn't have to keep track of which version of Python we're linking with this week or in this distribution (to choose between "python-six" and "python3-six") * Thus, it would be useful if we would guarantee that six was available for use with any Python-enabled GDB we ship, so that packages that want to use six to implement the 2/3 agnosticism don't have to worry about whether it will be available; anyone using our GDB will have it already, and anyone with their own GDB will presumably be able to figure it out from the ImportErrors. Back to the overall topic of switching to Python 3, I *still* don't see any reason to rush this, and I'm fairly certain that there are a *lot* of unpackaged scripts that will need fixing to work with both versions. Even Fedora, with their bleeding-edge debugging infrastructure, do not plan to switch until Fedora 22, and Fedora 21 hasn't even entered freeze yet. The only scripts *I* found that were already 2/3 agnostic were the ones bundled with GDB, which wasn't particularly encouraging to me. I admit my choice of places to look wasn't particularly scientific -- I basically just went to see whether the pretty printers I had written for crawl still worked, and GDB complained about my qattach.py script, then about the libstdc++ pretty-printers, and then also about the crawl pretty printers. I'm also feeling more and more that we need to ship GDB built both ways so that people can easily test their Python code with both, and that it should be forbidden to declare a Breaks on one or the other just because your -gdb.py happens not to work with it, since there's more to a package than -gdb.py. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
