Re: [Fink-devel] python modules do not comply with policy
On Friday, Apr 4, 2003, at 00:08 Australia/Sydney, Peter O'Gorman wrote: On Thursday, April 3, 2003, at 10:57 PM, Jeff Whitaker wrote: So, I'll create numeric-py22 and pil-py22 packages ASAP and put them in experimental/jswhit. If you were here, I'd kiss you :-) Thanks, if you do not wish to maintain those packages, put my name on them. Jeff, any chance of a pmw-py22 package as well, don't mine maintaining it. Matt --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Thursday, April 3, 2003, at 10:57 PM, Jeff Whitaker wrote: So, I'll create numeric-py22 and pil-py22 packages ASAP and put them in experimental/jswhit. If you were here, I'd kiss you :-) Thanks, if you do not wish to maintain those packages, put my name on them. Peter --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Thu, 3 Apr 2003, Peter O'Gorman wrote: > > On Thursday, April 3, 2003, at 04:29 PM, Rohan Lloyd wrote: > > It works pretty well for emacs, What do you think? > > Although I quite like this idea, what about compiled C python modules, > the binaries are not compatible across python versions? Peter: This is the killer. I found the Debian python policy (http://lists.debian.org/debian-python/2001/debian-python-200109/msg00069.html). Basically, it says that if a python module is needed for an older version of python, an pythonmodul-pyXY should be created that installs in /sw/lib/pythonXY/site-packages. In other words, I think your original suggestion is the right one. So, I'll create numeric-py22 and pil-py22 packages ASAP and put them in experimental/jswhit. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/CDC1FAX : (303)497-6449 325 BroadwayWeb : http://www.cdc.noaa.gov/~jsw Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124 --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Thursday, April 3, 2003, at 04:29 PM, Rohan Lloyd wrote: It works pretty well for emacs, What do you think? Although I quite like this idea, what about compiled C python modules, the binaries are not compatible across python versions? Peter --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Thursday, April 3, 2003, at 11:50 AM, David R. Morrison wrote: The problem with perl is similar, but not identical. Many perl modules work just fine with all versions of perl, and those don't necessarily need to be segregated from each other. Once I get the bindist out the door, I plan to work on getting multiple versions of perl coexisting with fink. For perl modules that *do* require separate compiles for each perl version, this is going to introduce the same headache we are now discussing with python. Emacs packages have a similar problem. With multiple emacs flavours installed, the .el files have to be byte compiled for each flavour. For the full details of how it works, have a look in /sw/share/doc/emacsen-common/debian-emacs-policy For Perl and Python, a similar approach could be used. For instance, with python, we could have the following directory structure: /sw/share/python/site-packages /sw/share/python2.2/site-packages /sw/share/python2.3/site-packages .py files get installed into /sw/lib/python/site-packages, and then compiled for each flavour of python and the resulting .pyc and .pyo files put into /sw/lib//site-packages Each flavour of python would be modified to include /sw/lib//site-packages in its path. A package called python-common would be created. It would provide scripts: /sw/lib/python-common/python-package-install /sw/lib/python-common/python-package-remove A python package "foo" must call /sw/lib/python-common/python-package-install foo in the postinst and /sw/lib/python-common/python-package-remove foo in the prerm These scripts call the package provided install/remove scripts in /sw/lib/python-common/packages/install/ /sw/lib/python-common/packages/remove/ which are responsible for doing the byte compiling on install and removing the byte compiled files on remove. These scripts are called both when a package is installed/removed and when a flavour is installed/removed. See the debian-policy for details. It works pretty well for emacs, What do you think? -- Rohan Lloyd --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Wednesday, Apr 2, 2003, at 20:50 US/Eastern, David R. Morrison wrote:
The problem with perl is similar, but not identical.
Many perl modules work just fine with all versions of perl, and those
don't necessarily need to be segregated from each other.
Once I get the bindist out the door, I plan to work on getting multiple
versions of perl coexisting with fink. For perl modules that *do*
require separate compiles for each perl version, this is going to
introduce the same headache we are now discussing with python.
Perhaps we could revise an old solution to match new problems:
How about two new tags: 'CompilerABI:' and 'CompatibleABI:',
Packages (Compiled Perlmods, Python mods, C++ programs, etc) that need
a specific ABI:
Package: foo-pm
RequireABI: perl (5.6.0, 5.8.0), python (21, 22)
Packages that provide an ABI (Perl 5.{6,8}.0, Python 2{1,2,3}, C++
3.{1,2}):
Package: perl
Version: 5.8.0
ProvideABI: perl (5.8.0)
Then, the dpkg name has the following appended to it:
-abi-ABI-VERS-abi-ABI-VERS...
alphabetically sorted by abi name, for example:
foo-pm would be foo-pm-abi-perl-5.8.0-abi-python-21 and depend on
abi-perl version 5.8.0 and abi-python version 21
ProvideABI: would automatically provide abi-ABI-VERSION, and RequireABI
would automatically generate a package
with the proper name that requires abi-ABI-VERSION for whatever ABI is
available, but should be automatically removed
and/or rebuild if the user wants to remove the only package providing
that ABI.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++:- a16 C>$ UB/L/X/*(+)>$ P+++()>$
L+++(++) E W++(+) N+++(++) o? K? w---(-) O? M++ V? PS+() PE+(-) Y+
PGP? t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h! !r-- !y?
--END GEEK CODE BLOCK--
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
The problem with perl is similar, but not identical. Many perl modules work just fine with all versions of perl, and those don't necessarily need to be segregated from each other. Once I get the bindist out the door, I plan to work on getting multiple versions of perl coexisting with fink. For perl modules that *do* require separate compiles for each perl version, this is going to introduce the same headache we are now discussing with python. -- Dave --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Wednesday, April 2, 2003, at 03:56 PM, Peter O'Gorman wrote: On Thursday, April 3, 2003, at 03:09 AM, [EMAIL PROTECTED] wrote: I sure hope not. I don't have the time to maintain all those variants. Yes, I know it is a pain, but I don't see a way around it, at least the current version of sketch has no hope of working with python-2.3 due to changes made in python's _tkinter module and the fact that sketch has it's own paxtkinter module which does the same thing with minor differences. So far all my attempts at patching paxtkinter to be compatible with python-2.3 have failed. I hope that the author will eventually release a new version of sketch which is compatible with python-2.3 (he should have a better idea of how to fix it than I). But all this is a little beside the point :). When I asked Dave Morrison on #fink if this had been discussed, he suggested making all python modules builddepend on all versions of python, build themselves multiple times, and then splitoff the bits for each version. This would be a pain for those building from source, but could make the maintainers life a little easier. It is the same problem perl has, isn't it? How do we plan to solve the perl problem? With different directories and separate 5.8 packages was the plan, i thought. -Ben --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Thursday, April 3, 2003, at 03:09 AM, [EMAIL PROTECTED] wrote: I sure hope not. I don't have the time to maintain all those variants. Yes, I know it is a pain, but I don't see a way around it, at least the current version of sketch has no hope of working with python-2.3 due to changes made in python's _tkinter module and the fact that sketch has it's own paxtkinter module which does the same thing with minor differences. So far all my attempts at patching paxtkinter to be compatible with python-2.3 have failed. I hope that the author will eventually release a new version of sketch which is compatible with python-2.3 (he should have a better idea of how to fix it than I). But all this is a little beside the point :). When I asked Dave Morrison on #fink if this had been discussed, he suggested making all python modules builddepend on all versions of python, build themselves multiple times, and then splitoff the bits for each version. This would be a pain for those building from source, but could make the maintainers life a little easier. Also, I would be willing to be the maintainer of numeric-py22 and pil-py22, I wouldn't make such packages and then make you the maintainer :-). If necessary, I will take maintainership for all versions/variants of those packages. Debian python modules Depend: python (>= 2.2), python (<< 2.3)... as far as I know fink can't deal with that. Thanks, Peter --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Wednesday, Apr 2, 2003, at 23:57 Australia/Sydney, Peter O'Gorman wrote: Hi, Depending upon which version of python is installed, the modules will go into a different place (/sw/lib/python-/site-packages). Now, this is a problem for me, and I think I will have to make numeric-py22 and pil-py22 packages in order for sketch to work without having to answer a bunch of mails saying to install python-2.2 as sketch will not work with python-2.3. This is doable. So the question arises, do we need to do something similar for all python modules? i.e. have a bunch of package-py21 package-py22 package-py23 packages for python modules? It would make them build the same .deb for all users regardless of what the user has installed ( policy, I believe ). Open for discussion/suggestions. I completely agree here as I have the same problem with pymol, and the only answer I see is to do as you say with all the python modules, I also need a least a pmw-py22. Matt --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python modules do not comply with policy
On Wed, 2 Apr 2003, Peter O'Gorman wrote: > Hi, > > Depending upon which version of python is installed, the modules will > go into a different place (/sw/lib/python-/site-packages). Peter: Yes - this is true. > > Now, this is a problem for me, and I think I will have to make > numeric-py22 and pil-py22 packages in order for sketch to work without > having to answer a bunch of mails saying to install python-2.2 as > sketch will not work with python-2.3. This is doable. The only other way around this is to rebuild all python modules when you change python versions (i.e going from python22 to python23). Python bytecode is not compatible between python versions, so you can't in general use numeric compiled with python22 in python23 and vice-versa. > > So the question arises, do we need to do something similar for all > python modules? > i.e. have a bunch of package-py21 package-py22 package-py23 packages > for python modules? I sure hope not. I don't have the time to maintain all those variants. > > It would make them build the same .deb for all users regardless of what > the user has installed ( policy, I believe ). I know Debian has struggled with this as well - we should go look and see how they do it. Right now, rebuilding all modules when you change python versions is the only thing that works (and I agree it violates the letter of the law). Thanks for bringing this up Peter - I think it is an important issue. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/CDC1FAX : (303)497-6449 325 BroadwayWeb : http://www.cdc.noaa.gov/~jsw Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124 --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
