Re: Debian Python policy Upgrade Path (draft/proposal)
On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote: Matthias Klose [EMAIL PROTECTED] writes: [...] exactly. But you see that these packages will break when you try to upgrade. We can't make 2.1 the default right now, because we will _silently_ break packages. Before python can point to python2.1, we will have to fix all packages which depend on python-base, to depend on python-base ( 1.6). But if we get Python 2.1 into Debian 3.0, people will be upgrading from the old Python 1.5 packages in Debian 2.2 directly to the new packages, and unless they use apt-get dist-upgrade to upgrade to the newest versions of everything, packages will still be broken. For that matter, just getting everyone using testing to transition over to the new versions properly will be nearly impossible unless there are appropriate conflicts and dependencies to make sure that only working combinations of packages can be installed. Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Debian Python policy Upgrade Path (draft/proposal)
Donovan Baarda [EMAIL PROTECTED] writes: Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. Another possibility is for python-base to go away, and for a new package that conflicts with it, and has a different name, to take its place. In stable, it seems that only bg5ps, grmonitor, pythondoc and sketch depend on python, compared to 59 which depend on python-base, so this would make the Conflicts field just a little bit shorter. (Actually 60, but gimp-python also depends on python-base ( 1.6.0)). Packages that depend on python: grep-dctrl -FDepends -e 'python([ ,]|$)' Packages Packages that depend on python-base: grep-dctrl -FDepends python-base Packages It seems things have gotten worse... I count 22 packages in unstable that depend on python, and around 101 that depend on python-base only once. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Debian Python policy Upgrade Path (draft/proposal)
Carey Evans writes: Matthias Klose [EMAIL PROTECTED] writes: [...] 2.4. Dependencies - Packaged modules must depend on `python-base ( X.Y)' and `python-base ( X2.Y2)'. (= X.Y), right? Shouldn't this explain just what X2.Y2 is? I assume it's actually X.Y+1, i.e. =1.5 and 1.6, =2.1 and 2.2, =2.9 and 2.10, etc. Thanks. Updated in 0.3.2: http://ftp-master.debian.org/~doko/python/
Re: Debian Python policy Upgrade Path (draft/proposal)
Donovan Baarda writes: On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote: Matthias Klose [EMAIL PROTECTED] writes: [...] exactly. But you see that these packages will break when you try to upgrade. We can't make 2.1 the default right now, because we will _silently_ break packages. Before python can point to python2.1, we will have to fix all packages which depend on python-base, to depend on python-base ( 1.6). But if we get Python 2.1 into Debian 3.0, people will be upgrading from the old Python 1.5 packages in Debian 2.2 directly to the new packages, and unless they use apt-get dist-upgrade to upgrade to the newest versions of everything, packages will still be broken. The only reason not to go to 2.1 directly is not breaking the packages in unstable.
Re: Debian Python policy Upgrade Path (draft/proposal)
Carey Evans writes: Donovan Baarda [EMAIL PROTECTED] writes: Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. It is probably better. Currently a package maintainer cannot make a final version of his package, depending on python-base, if he wants to use python2.1. Another possibility is for python-base to go away, and for a new package that conflicts with it, and has a different name, to take its place. basically that is Neil's proposal of a python-api package. In stable, it seems that only bg5ps, grmonitor, pythondoc and sketch depend on python, compared to 59 which depend on python-base, so this would make the Conflicts field just a little bit shorter. It seems things have gotten worse... I count 22 packages in unstable that depend on python, and around 101 that depend on python-base only once. well, I count 121 ... we could get this down to 63 for the woody release. So if we do this, we should inform the package maintainers ... - either depend on python-base (= 2.1), python-base ( 2.2) - or depend directly on python2.1-base (python2 is going to be dropped), or if not possible on python1.5-base, and call the versioned interpreter explicitely (python1.5, python2.1). appended is a Conflicts: line for a new python-base (2.1) and a list of maintainers/packages which are affected. python-base (2.1) Conflicts: bg5ps (= 1.3.0-1), cfv (= 1.9-2), cooledit (= 3.17.1-2.2), cplay (= 1.43-1), dcoppython (= 2.2.1-1.2), doc-central (= 1.3), dput (= 0.8.9.1), entity-python (= 0.7.2-1), fetchmailconf (= 5.9.3-1), forg (= 0.03-1), fsh (= 1.1), gadfly (= 1.0-6), garchiver (= 0.5-1), getmail (= 2.1.3-1), gif2png (= 2.4.0-2), glimmer (= 1.0.8-4), gnats2w (= 0.15.2), gnumeric (= 0.72-0.1), gramps (= 0.5.1-1), grc (= 1.0.1), grmonitor (= 0.81-2), guppi (= 0.35.5-4), htmlgen (= 2.2.2-4), iceme (= 1.0.0-2), icepref (= 1.1-7), ilu-base (= 2.0.0.91-3), imgsizer (= 2.1-1), ipcheck (= 0.132-1), jack (= 2.99.6-2), jaxml (= 2.22-1), junior-programming (= 1.1), kdelibs3 (= 4:2.2.1-12), kdesdk-scripts (= 2.2.1-3), kivio (= 1:1.1.0-final-6), knewsticker-scripts (= 2.2.1-2), libguppi11 (= 0.35.5-4), libwxgtk2.2-python (= 2.2.6.1), lilypond (= 1.4.8-1), linbot (= 1.0.0-2), lincredits (= 0.2), luci (= 0.1.1-1.1), lyx (= 1.1.6fix3-2), lyx-cjk (= 1.1.6fix3-1), mailman (= 2.0.6-1), muttzilla (= 0.40-9), omniorb (= 1:3.0.4-2.1), plucker (= 1.1.13-1), plwm (= 2.3-1), pms (= 0.2.17-1), poxml (= 2.2.1-3), pybliographer (= 1.0.9-5), pyching (= 1.0.4-2), pycmail (= 0.1), pydb (= 1.01-2), pydf (= 0.9.5), pydict (= 0.2.5.1-1), pyftpd (= 0.7), pyg (= 0.9.4-7), pyrite-publisher (= 1.99.2-1), pysol (= 4.60-1), python-4suite (= 0.11.1-2), python-bobo (= 2.1.4-5), python-bobodtml (= 2.2.1-5), python-bobopos (= 2.1-4), python-cddb (= 1.3-3), python-distutils (= 1.0.2-1), python-extclass (= 1.2-4), python-gdk-imlib (= 0.6.8-8), python-gendoc (= 0.73-5), python-glade (= 0.6.8-8), python-gtk (= 0.6.8-8), python-gtkglarea (= 0.6.8-8), python-happydoc (= 1.5-1), python-id3 (= 1.0-1), python-imaging (= 1.1.2-3), python-kjbuckets (= 2.2-6), python-mxdatetime (= 1.3.0-5), python-mxstack (= 0.3.0-4), python-mxtexttools (= 1.1.1-3), python-mxtools (= 1.0.0-4), python-mysqldb (= 0.9.0-1), python-newt (= 0.50.17-7), python-numeric (= 17.1.2-6), python-numeric-tutorial (= 17.1.2-6), python-orbit (= 0.3.0-2), python-orbit-dev (= 0.3.0-2), python-pam (= 0.4.2-3), python-pcgi (= 1.999a5-2), python-pygresql (= 7.1.3-4), python-pyqt (= 2.5-1), python-reportlab (= 1.08-1), python-slang (= 0.2.0-1), python-soap (= 0.8-1), python-stats (= 0.5-1), python-unit (= 1.4.1-1), python-utmp (= 0.4), python-vtk (= 3.1.2-1), python-xlib (= 0.8-1), python-xml (= 0.6.6-2), python-xmlrpc (= 0.8.6-3), pythondoc (= 0.6-2), quantlib-python (= 0.2.0-1), reportbug (= 1.31), routeplanner (= 0.11), routeplanner-gnome (= 0.11), scanerrlog (= 2.00-1), scigraphica (= 0.7.1-5), scigraphica-gnome (= 0.7.1-5), sgmltools-lite (= 3.0.3.0.cvs.20010909-3), sip (= 2.5-2), snappea (= 3.0d3-8), subterfugue (= 0.2-1), sulfur (= 0.1.3), syslog-summary (= 1.10.1), twisted (= 0.10.2-1), viewcvs (= 0.7-3), woody (= 0.1.6-2), xanim-modules (= 2.80.1.12), xbel-utils (= 0.6.6-2), xracer-tools (= 0.96.9-10), zope-bytecodehacks (= 0.1.7-2) The package list sorted by maintainer: JP Sugarbroad taral at taral.net ['scanerrlog', 'jaxml'] Dr. Guenter Bechly gbechly at debian.org ['iceme'] Ron Lee ron at debian.org ['libwxgtk2.2-python'] Danie Roux droux at tuks.co.za ['garchiver'] Matthias Klose doko at debian.org ['python-numeric', 'python-numeric-tutorial', 'python-distutils']
Re: Debian Python policy Upgrade Path (draft/proposal)
Donovan Baarda writes: Good point... I'd forgotten about that. This means we might as well go strait to python2.1 as the default, but make sure that the python2.1-xxx packages have versioned conflicts with all the packages that depend on just python or python-base and install into /usr/lib/python1.5/. Perhaps the best way to do this is have python-base (2.1xxx) have all the conflicts, allowing the other packages to be relatively clean. I've made python packages defaulting to 2.1 (not in incoming) and have put them on ftp-master. deb http://ftp-master.debian.org/~doko/python ./ There is a second (currently empty) directory writable for Debian, which could serve as a place to collect NMUs for the new schema. deb http://ftp-master.debian.org/~doko/python-nmus ./ Comments are welcome.
Re: Proposed modification to the Python Policy
Matthias Klose [EMAIL PROTECTED] writes: Jérôme Marant writes: I do propose that we install all architecture independant modules in /usr/share and all architecture dependent modules in /usr/lib as it has always been. assume we have a package with an architecture independant module and an architecture dependent module. Then we have to split it in share and lib? ugly. And it's unsupported upstream by distutils. I made a mistake: i should have said files rather than modules. No need to split the package. This would make sense IMHO. (BTW, Brendan O'Dea did the same with perl). For instance, all lib-dynload files would go to /usr/lib and all .py would go to /usr/share With distuptils, you can do that with some options among the following: Options for 'install' command: --prefixinstallation prefix --exec-prefix (Unix only) prefix for platform-specific files --home (Unix only) home directory to install under --install-base base installation directory (instead of --prefix or -- home) --install-platbase base installation directory for platform-specific files (instead of --exec-prefix or --home) --root install everything relative to this alternate root directory --install-purelib installation directory for pure Python module distributions --install-platlib installation directory for non-pure module distributions --install-lib installation directory for all module distributions (overrides --install-purelib and --install-platlib) I don't see this proposal as necessary for the transition from 1.5 to 2.1, so I would like to see it not as part of the policy during the transition. No, this is not necessary but as we are writing the Policy, I would like to see it for the near future. I am personaly ready to implement this in my packages. Cheers, -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: python upgrade
On Thu, Oct 18, 2001 at 07:25:04PM +0200, Matthias Klose wrote:
hmm, seems I've been kicked of the debian lists. anyway, could you
implement the scripts for your c) proposal? would it be a good idea to
put the debian directories under CVS control, so we have access to it?
And I thought perhaps I'd been annoying people too much and people had
redirected my posts to /dev/null :-)
I've not look in my mail till now, and there seems to be a plethora of
people posting solutions. I feel we are starting to approach the point of
too many cooks, and am tempted to back out rather than add more confusion.
Now that Neil is back, I see he has posted that he has some scripts ready
for this, and I'd trust that his are worth using. However, if you are still
interested, I have started down the path of experimenting with various
preinst and prerm scripts based on the 2.1 packages in unstable. Even if you
don't want to use them, they might provide ideas.
The files attached are;
pythonX.Y-base.postinst
pythonX.Y-base.prerm
postinst and prerm scripts should be usable for all pythonX.Y-base packages,
just redefine VERSION at the start.
update-python
A script to be called by version independant python packages in their
postinst and postrm scripts. This should probably be provided by the
python-base package.
Note that these scripts are _untested_. They assume the following directory
structure;
/usr/lib/pythonX.Y/ pythonX.Y installation directory
/usr/lib/python/version independant packages installation directory
/usr/local/lib/python/X.Y local version dependant modules
/usr/local/lib/python/ local version independant modules
They create and compile symlinks into the relevant */python/ directory in
*/pythonX.Y/ directories. They also clean up dangling symlinks and any
associated *.pyc or *.pyo files.
They have some minor deficiencies, the biggest being any directorys created
in */pythonX.Y/ directories during symlink creation will not be cleaned up.
This is a bit tricky, as it is hard to determine when directories are
created for symlinks, and when they are created by some other package.
Note that these scripts are very simple and would be easy to modify. In
particular, I'm not familiar with any /usr/local/python conventions, so they
probably need adjusting there.
--
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--
#! /bin/sh -e
#
# postinst script for the Debian python2.1-base package.
# Written 1998 by Gregor Hoffleit [EMAIL PROTECTED].
# Modified 2001 by Donovan Baarda [EMAIL PROTECTED].
#
VERSION=2.1
PACKAGE=python${VERSION}-base
case $1 in
configure|abort-upgrade|abort-remove|abort-deconfigure)
# Create /usr/local/lib/python/site-packages and
# /usr/local/lib/pythonX.Y/site-packages if needed
# /usr/local/lib/pythonX.Y/ is for local version dependant packages
# /usr/local/lib/python/ is for local version independant packages
for i in python python/site-packages python${VERSION}
python${VERSION}/site-packages; do
if [ ! -e /usr/local/lib/$i ]; then
mkdir -p /usr/local/lib/$i 2 /dev/null || true
chmod 2775 /usr/local/lib/$i 2 /dev/null || true
chown root:staff /usr/local/lib/$i 2 /dev/null || true
fi
done
# Update symlinks to /usr/lib/python/ and /usr/local/lib/python
# in /usr/lib/pythonX.Y/ and /usr/local/lib/pythonX.Y/.
# This will remove all dangling symlinks and any related *.pyc
# and *.pyo files. It will create absolute symlinks for everything
# in the */python/ directories. Any files that already exist in the
# */pythonX.Y/ directories will be left untouched.
for i in /usr/lib/python /usr/local/lib/python; do
find $i${VERSION}/ -type l -not \
\( -xtype f -or -xtype d -or -xtype l \) \
-exec rm -f \{\} \{\}o \{\}c \; 2 /dev/null || true
cp -Rs $i/* $i${VERSION}/ 2 /dev/null || true
done
# Compile everything in /usr/lib/pythonX.Y and /usr/local/lib/pythonX.Y
for i in /usr/lib/python${VERSION} /usr/local/lib/python${VERSION} ; do
/usr/bin/python${VERSION} -O
/usr/lib/python${VERSION}/compileall.py -q $i
/usr/bin/python${VERSION} /usr/lib/python${VERSION}/compileall.py
-q $i
done
;;
*)
echo postinst called with unknown argument \`$1' 2
exit 1
;;
esac
if [ $1 = configure ]; then
ldconfig
fi
# Automatically added by dh_installdocs
if [ $1 = configure ]; then
if [ -d /usr/doc -a ! -e /usr/doc/python2.1-base -a -d
/usr/share/doc/python2.1-base ]; then
ln -sf ../share/doc/python2.1-base /usr/doc/python2.1-base
fi
fi
# End
