Pierre Habouzit <[EMAIL PROTECTED]> writes: > python-support is written in python (same is true for python-central) > and will *always* depend upon 'python'
Maybe some examples to illustrate will help. It may not be entirely clear why the above statement doesn't actually resolve the problem. Suppose that, due to some changes to how byte-compiling is done for Python 3.0, it's necessary to write the script in python-support to require Python 3.0. It therefore might depend on python3.0 instead of python, and hence wouldn't cause a /usr/bin/python to be installed. Suppose that with Python 4.0, the python-support script, still written in Python, makes sense to distribute as an executable compiled to native code and therefore depending on Python libraries but not needing an interpreter at all. You can decide that installing python-support is a way to get a /usr/bin/python interpreter, but there's no inherent reason why this should be the case. Furthermore, I don't think that's actually the right approach. It adds complexity to dependency analysis without really gaining anything. Let me turn this around: what advantage is there to the current approach? Why would you ever want a package containing a Python script to depend on python-support and *not* python? Is this just saving eight bytes in the Depends field, and if so, is that really worth it for, say, not being able to locate all packages that depend on Python by simply looking for packages that depend on Python (rather than having to also factor in packages that use transitive dependencies)? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
