Re: Maintaining Python 1.5
On Tue, 10 Sep 2002, Matthias Klose <[EMAIL PROTECTED]> wrote: > I do not mind passing the maintainership, but I do mind keeping it in > unstable. Debian is not a museum for old python versions. What hinders > you to install the python1.5 packages from woody in unstable? apt > tagging is your friend. Until Python 1.5 is truly dead, many people who use Debian as a development platform need to check Python1.5 compatibility. For the sake of this argument, I'd say Python 1.5 is dead when it's no longer the Red Hat default Python version. If you don't want it in unstable, fine -- don't maintain it.
Re: dependencies of non-module packages
On Sun, Sep 08, 2002 at 02:49:24PM +0200, Tollef Fog Heen wrote: > * Graham Wilson > > | On Sun, Sep 01, 2002 at 09:08:36AM +0200, Tollef Fog Heen wrote: > | > Until dpkg supports triggers, I think what the emacsen does it the > | > most sane -- I'd be really, really happy if python modules/apps were > | > | what do the emacsen do? > > Each package provides a shell script which byte-comiles the package's > files. If a new emacsen is installed, it will call emacsen-install, > which in turns calls each of the already-installed extension packages' > install script. > > Those scripts get a parameter saying which emacsen which is being > installed, so they can decide whether they work with that version or > not. If they don't work with that version, then what? Are dependancies used to ensure packages are not installed without a compatible version of emacs? Can emacs support parallel installation of multiple versions of emacs? Where are the compiled files kept for each installed version? By convention Python likes to keep it's *.pyc files in the same directory as the *.py files. This means you either support a single version of python at a time (ie, the default "python"), or you provide different directories for each supported version of python (ie, /usr/lib/python2.1, /usr/lib/python2.2, etc). How does emacs handle this? > One has a similar emacs-remove script, which removes the byte-compiled > files, either when an emacsen is being uninstalled or the package > itself is being uninstalled. I prefer to use the existing dpkg database and package scripts where possible, rather than adding extra scripts and/or a "registry". The existing dpkg facilities can support this functionality, so why add extra stuff that just replicates it? -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: dependencies of non-module packages
* (Donovan Baarda) | On Sun, Sep 08, 2002 at 02:49:24PM +0200, Tollef Fog Heen wrote: | > Those scripts get a parameter saying which emacsen which is being | > installed, so they can decide whether they work with that version or | > not. | | If they don't work with that version, then what? Are dependancies used to | ensure packages are not installed without a compatible version of emacs? yes (that at least one version which with the package works is installed). | Can emacs support parallel installation of multiple versions of emacs? Where | are the compiled files kept for each installed version? in a version-specific load-dir. | By convention Python likes to keep it's *.pyc files in the same directory as | the *.py files. This means you either support a single version of python at | a time (ie, the default "python"), or you provide different directories for | each supported version of python (ie, /usr/lib/python2.1, | /usr/lib/python2.2, etc). How does emacs handle this? if you want to do that, the python-install script would copy the .py files and compile them and not remove them afterwards. | > One has a similar emacs-remove script, which removes the byte-compiled | > files, either when an emacsen is being uninstalled or the package | > itself is being uninstalled. | | I prefer to use the existing dpkg database and package scripts where | possible, rather than adding extra scripts and/or a "registry". The existing | dpkg facilities can support this functionality, so why add extra stuff that | just replicates it? unless you ship byte-compiled files in the package, it doesn't. so, you need to add this stuff one way or another. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Maintaining Python 1.5
Matthias Klose wrote: > Moshe Zadka writes: > > I was wondering if you mind passing Python 1.5 maintainership to me. > > I do not mind passing the maintainership, but I do mind keeping it in > unstable. I don't think it is up to individual Debian developers to decide what packages should be allowed in Debian. Neil
Re: Maintaining Python 1.5
Neil Schemenauer writes: > Matthias Klose wrote: > > Moshe Zadka writes: > > > I was wondering if you mind passing Python 1.5 maintainership to me. > > > > I do not mind passing the maintainership, but I do mind keeping it in > > unstable. > > I don't think it is up to individual Debian developers to decide what > packages should be allowed in Debian. ??? Interisting. So I am allowed to package perl3, quichote-0.1 and marlais 0.5?
Re: Maintaining Python 1.5
On Wednesday 11 September 2002 15:00, Matthias Klose wrote: > Neil Schemenauer writes: > > Matthias Klose wrote: > > > Moshe Zadka writes: > > > > I was wondering if you mind passing Python 1.5 maintainership to me. > > > > > > I do not mind passing the maintainership, but I do mind keeping it in > > > unstable. > > > > I don't think it is up to individual Debian developers to decide what > > packages should be allowed in Debian. > > ??? Interisting. So I am allowed to package perl3, quichote-0.1 and > marlais 0.5? If you wanted to and could make sure it did not break anything, why not. I could definately see something like this making sense in a corporate setting. A Debian devel may not be allowed to upgrade some of their boxes and it would be easier to use foo X.Y on all platforms than deal with the compatibility. This is also why it makes sense to keep python1.5 around. As Moshe points out python1.5 is still the python most RH users get and it is way too easy to let a 2.x ism into your code. Hell on a python list this morning I was reminded that a solution I proposed only works in 2.2.1+.
Re: #158930: python-pmw needs rebuilt against python 2.2
On Sun, Sep 08, 2002 at 01:15:55PM -0400, Jack Howarth wrote: >Actually on second thought we better stick with the current > python-pmw_0.8.5-6 adjusted to build against python 2.2. Things > like pymol are having issues running with pmw 1.1. The patches > required to get python-pmw_0.8.5-6 built with python 2.2 are > attached below... Thanks in advance. I've uploaded a NMU to DELAYED/5-day. cheers, Michael
