On Mar 23, 2014, at 8:31 AM, Derek Homeier <de...@astro.physik.uni-goettingen.de> wrote:
> On 20.03.2014, at 4:20PM, Daniel Johnson <daniel.johnso...@gmail.com> wrote: > >> I agree. There's no reason to keep 2.6 around as 2.7 is fully backward >> compatible. >> > Just an aside, anyone aware of any major Linux distros that still only > provide 2.6? > This was an issue for many packages like numpy to keep support for older > versions, > since some places like large companies or computing centres would only upgrade > on something like 5-year cycles; this in turn would be a potential incentive > for developers > to keep a 2.6 installation for testing purposes. Not saying that this has to > be provided > by fink though if it's too much maintenance. After all one could relatively > easily maintain > private copies in the local branch, if really needed. I know that older debian releases have 2.6 though Squeeze has 2.7 and 3.2. I'm sure there's plenty of 2.6s and even 2.5s floating around. 2.6 and 2.7 are very similar so maintaining compatibility between them isn't that hard. The fink python26 package is still in CVS history of course so if someone wants to resurrect it it wouldn't be hard. Also you could download it from python.org if you wanted it for testing purposes. We have limited resources so anything that reduces maintenance costs is good. :) > >> It's also reasonable to kill 3.1 as it's now unsupported upstream. 3.3 and >> the just released 3.4 will stay of course, but we might also consider >> killing 3.2 even though it still gets patches. 3.3 introduced better >> backward compatibility with 2.7 to ease porting to 3.x and vastly improved >> unicode string handling. >> >> There are no language changes between 3.3 and 3.4, just new and updated >> library modules, so if maintainers can add 3.4 variants to their packages >> that would be awesome. > > Big +1 to get rid of 3.1! Already done. :) > > Does anyone know btw if 3.4 already comes with full setuptools support > included? > It has a %i/bin/easy_install-3.4, and I was able to build and test coverage, > nose > and numpy without installing it, so maybe a change is in order to > > *Depends: ( %type_pkg[python] <= 33 ) setuptools-tng-py%type_pkg[python] It's not supposed to. :( I thought I'd disabled the installation of setuptools and pip but apparently the python build system isn't respecting the settings. Python 3.4 started bundling pip (which requires setuptools) as a standard packaging system. Unfortunately, that conflicts with fink's packaging since we can't know what packages users might install on their own. The configure script has a --without-ensurepip option which is supposed to not install pip, but it doesn't seem to work. A further problem is that installation of pip/setuptools is only performed if it isn't already present in site-packages. So the first time you build python34, they get installed. But if you rebuild python34 or install a newer version, they DON'T get installed but are, of course, overwritten by dpkg when the new package is installed. What a mess. I'm going to have to think about this some more. I either need to always install them or never install them but there doesn't seem to be any easy way to do that. :( Best to avoid using python34 for now. Daniel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
