> Oh, I need this pyX package... Let's download it. You're using a python module name because you need to import it. If you want to import modules, you want the binary package name; if you want to work on the source package then you need *either* the binary package name or the source package name as others have already pointed out. Knowledge of source package names isn't required.
(I'll assume that your X in pyX was a placeholder... given that there is actually a pyx source package and a python-pyx binary package and debian package names are downcased, it's actually a rather confusing example to pick... using a policy-compliant lower case name "apt-get source pyx" or "apt-get source python-pyx" both work just fine.) Binary package names for module packages already follow the python policy of being python-foo where you want to "import foo". The thing that we do not easily get from this is the case when we "import foo.bar" and we need to work out if that's in the "python-foo" package or perhaps in a "python- foo.bar" package. At present we have apt-file or dpkg -S to deal with this problem and in the future, as noted by Paul, DEP11 will give us a way of discovering this information much more easily (and this a common problem for perl and java and …). This module discovery is orthogonal to source package naming; note that exactly the same problem exists in trying to work out if foo and foo.bar were the same or different source packages no matter what naming scheme you want to come up with. If your py$X in your example is not in a binary package called python-py$X and it is a public module-only package then it's already not policy compliant and wants fixing. Report a bug about the binary package name. Cite the appropriate part of python policy in it. If the module is in a policy- compliant binary package then your problem is already solved as has been already pointed out so there's nothing to fix here. Knowledge of the source package name was not required. Also note that your example of trying to find source package names by divination is still not going to work problem where a python module is provided as bindings its own C library. There are many sources like these -- let's look at one such example: xapian-bindings Package-List: libxapian-ruby1.8 deb ruby optional libxapian-ruby1.9.1 deb ruby optional python-xapian deb python optional tclxapian deb libs optional So that source package should be renamed to python-xapian because the python people want unified source package naming? Clearly not. And once you know you have a pile of exceptions to whatever naming scheme you want, it's not a useful naming scheme -- you'll be back to either (a) stumbling around trying things at random as per your examples or (b) using the tools we have that accept either binary or source package names or (c) using the available tools to look up the correct information to feed to git svn. > And that's just an example on what can go wrong and be really annoying. > It's even more annoying when you are trying to do a "git svn clone" > which takes forever. If you want to get the VCS data for the python-foo binary package: $ apt-cache showsrc python-foo | grep Vcs Knowledge of the source package name was not required. Like the other apt- get commands shown by others, apt-cache showsrc takes binary package names as well as source package names. I guess it will take less than forever to write the appropriate 2 line shell script to solve this problem for you as your own replacement to the existing debcheckout. (Or perhaps you'd like to add a couple of lines to debcheckout to offer git-svn there? line 526 looks like the right place for you to start -- debcheckout is in the devscripts package for submitting patches to the bts.) Making use of existing tools and extending them where necessary so that they always work seems a lot more useful than creating some sort of flawed naming scheme that will only ever sometimes work. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint BE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/krmamp$p1j$1...@ger.gmane.org
