[please CC me, I'm not on the list]
Hypothetical situation:
Source package: contains foo.py (python module, works with every python
version under the sun) and foo (a script whose first line is
"import foo"). I want to properly support people who want 2.1 and 2.2.
There are several audiences here:
1. People who want to use "foo"
2. People who want to develop against "foo.py"
Multiplied by
1. People who have python2.1 only
2. People who have python2.2 only
3. People who have python2.1 and python2.2
I'm generating a python2.1-foo and python2.2-foo containing foo.py, as
per draft policy.
Here are alternatives for where to put /usr/bin/foo:
1. in python2.1-foo and python2.2-foo, in /usr/bin/foo, making them conflict
Pros: easy enough for me.
Cons: people who develop against foo.py cannot check for 2.1 and 2.2
compatibility without lots of pain
2. in py2.1-foo and py2.2-foo, as /usr/bin/foo2.{1,2}, manage symlinks
via alternatives
Pros: no conflicts
Cons: high maintainence: every script added to the package must
be echoed in my postinst/prerm, priority must take into account
debian default version
3. in py2.1-foo-bin and py.2.2-foo-bin, which depend on an appropriate
py2.x-foo package, and Provide: Replace: and Conflict: py-foo-bin
Pros: easy for me, no conflicts of python modules
Cons: people who want some users to run foo2.1 and some to run foo2.2
(perhaps foo reads a config file, and the users want to program
the config file in the appropriate version of python, or as
in my case, foo keeps state in pickles) cannot
There are, of course, lots of variants possible on these two.
My question is two-fold:
a. Was anyone in this situation? What did you do?
b. Should we document a best current practice in the now-being-written
developer reference? next version of draft policy?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
