> 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 Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprintBE65 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
