On Tue, Sep 18, 2012 at 10:10 PM, Allan McRae wrote:

Hi,

The recent lua-5.2 thread and also python-3 have highlighted the need for us to really have a policy for how we deal with providing two different versions of a language interpreter in the repos. This is particularly important when there is a period of time where we want to supply the newer version of the language, but much software has not transitioned to it yet so we must provide an old version too. Note I while i am specifically considering programming languages here, this could apply to libraries as well where we are force to provide an old version for some time.

There are two options that I see (assuming that us being Arch Linux always want the newest version in the repos...)

1) The "foo" package is the newest version of the language and the legacy version gets the version attached to it - i.e. "foo1". Libraries for the language "foo" would be called "foo-libname" and "foo1-libname"

2) Both packages have a version attached to their name. "foo2" and "foo1". Libraries for the language would be called "foo2-libname" and "foo1-libname"

Choosing which version:

#1 is best if we expect all software to be updated to the new version and the legacy version to be soon removed (e.g. for lua?).

#2 is best if we think we will continue to support both versions for an extended period of time (e.g. python2/3).

As long as we all agree that python should have been python3 ;)

Does that sound a reasonable policy? It would be up to the maintainer to decide whether to use naming scheme #1 or #2 based on expectations of the language's future.

Sure, this sounds reasonable to me. Maintainers just need to remember that the decision for legacy support should be strongly driven by the upstream future of the language -- e.g. Python2 will see fixes through 2015, but lua51 is being phased out on a much shorter timeline. There's also availability and ABI/API concerns that need to play into this. Of course, I'd hope that the upstream drives their support decision with this in mind, so this element of the decision shouldn't be too much of a concern for us downstream.

Comments? I'd like to get this sorted quickly so we can get the python and lua rebuilds done.

On Wed, Sep 19, 2012 at 4:10 AM, Allan McRae wrote:

Comments? I'd like to get this sorted quickly so we can get the python and lua rebuilds done.

My suggestion would be to simplify the both case into the first. Simpler is the policy, easier is to apply. Here we make 2 cases based on lua and python upstream behaviour. - python: Hardly break compatibility with long support for old version leading to a slow move of libraries and programs. - lua: Lightly break compatibily with short support for old version, leading to a fast move of libraries and programs. If we look closer at what python upstream do, they break compatibily even in minor version update. Not deeper as with 3.x bump, but some API are removed after a time of deprecation. This funny guy give some examples of incompatibilies ("with" becoming a keyword, raise of strings become forbidden) between python 2.4 and python 2.6 (despite the title of his article and what he claims) [1]. So we doesn't want have python2.4-foo and python2.6-foo because we think that library must follow upstream for small breakage and we want avoid maintaining λ versions in parallel. I'm not medium but upstream probably learn from this difficult move from python2 to python3 and If python3.X->python4.0 is not a big breaking like python2.7->python3.0 we don't want to rebuild all package with deps and rename all libraries. Same games for all others languages (lua, perl, ruby). So dropping old versions of a language is always dependents of: - upstream support ; - first class library moves ; - big software doesn't require it. About python I suggest to keep python-foo and python2-foo as long as needed. If python4 pop-up without breaking compatibilty python3-x will never be required as update will be smooth. If python4 break everything, we can have python-foo, python3-foo and python2-foo. Same idea for lua. So one case will suffice. About prefix of libraries I would suggest to don't be too strict in package naming and don't be redundant when a package name start by our prefix. It's a common case for languages libraries (e.g: luaposix[2], luafilesystem[3], pyqt[4], ruby-gnome2[5]). Do we want ruby-gnome become ruby-ruby-gnome2 package? Answer is probably here [6]. If our prefix is choucroute- and project name is choucrouteroxx, choucroute-roxx is smarter than choucroute-choucrouterox? Cheers, [1] http://regebro.wordpress.com/2010/02/12/yes-python-2-6-is-backwards-compatib... [2] http://luaforge.net/projects/luaposix/ [3] http://keplerproject.github.com/luafilesystem/ [4] http://www.riverbankcomputing.co.uk/software/pyqt/intro [5] http://ruby-gnome2.sourceforge.jp/ [6] https://www.archlinux.org/packages/community/i686/ruby-gtk2/ -- Sébastien "Seblu" Luttringer www.seblu.net