FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 09-19-2012, 02:10 AM
Allan McRae
 
Default Transitioning between incompatible language versions

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).


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.

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

Allan
 
Old 09-19-2012, 02:42 AM
Dave Reisner
 
Default Transitioning between incompatible language versions

On Tue, Sep 18, 2012 at 10:10 PM, Allan McRae <allan@archlinux.org> 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.
 
Old 09-23-2012, 02:25 AM
Sébastien Luttringer
 
Default Transitioning between incompatible language versions

On Wed, Sep 19, 2012 at 4:10 AM, Allan McRae <allan@archlinux.org> 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-compatible/
[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
 

Thread Tools




All times are GMT. The time now is 04:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org