Re: Removing zope
* Matthias Klose <[EMAIL PROTECTED]> [040403 12:25]: > Steve Langasek writes: > > On Wed, Mar 31, 2004 at 09:34:18PM -0600, Steve Langasek wrote: > > > On Mon, Mar 29, 2004 at 05:33:57AM -0500, Nathanael Nerode wrote: > > > > For zope to be removed, one must also do this: > > > > remove zope-textindexng2/2.05-1 > > > > remove zope-zpatterns/0.4.3p2-17 > > > > > Cc'ing the maintainers of those packages, as they have an obvious vested > > > interest in keeping zope from being removed from sarge. Any takers for > > > NMU'ing (or MU'ing) zope to get these RC bugs fixed? Time is short. > > > > also cc:ing the maintainers of the various other zope packages that > > are arch: all, and would also have to be removed in order for zope to be > > removed from testing. > > > > The total list of packages that must be removed if zope is not > > releasable with sarge is as follows: > > > > plone > > python-extclass > > qmtest > > The zope maintainers seem to be quiet ... Please before removing > qmtest, let me separate out the python-extclass package from the zope > package. No reaction from Luca indeed, but Andrea is suggesting to upgrade to his 2.7.0-13 package. During the next week, I'll try and see if that sounds possible and feasable without breaking to much other packages. Fixing the grave bugs in 2.6.4 doesn't look impossible, but then, I really don't like to mess with Luca's zopectl code... Gregor
Bug#177574: python-tal: Should conflict with python2.1-tal (<= 1.5.0)
Package: python-tal Version: 1.4.1-2 Severity: important python-tal 1.5.0-4 installs /usr/share/doc/python-tal, which is also installed by the stable package python2.1-tal (1.4.1-2). python-tal should hence conflict with python2.1-tal (<=1.4.1-2), so that the conflicting package is removed. Without that conflict, the upgrade fails with this error: Preparing to replace python-tal 1.4.1-2 (using .../python-tal_1.5.0-4_all.deb) ... Unpacking replacement python-tal ... dpkg: error processing /var/cache/apt/archives/python-tal_1.5.0-4_all.deb (--unpack): trying to overwrite `/usr/share/doc/python-tal', which is also in package python2.1-tal Errors were encountered while processing: /var/cache/apt/archives/python-tal_1.5.0-4_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Gregor -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux clapton 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=de_DE.ISO-8859-1, [EMAIL PROTECTED] Versions of packages python-tal depends on: pn python (<< 2.2) Not found. ii python2.1-tal 1.4.1-2Template Attribute Language
Re: 2 issues about zope-* packages
* Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> [020326 01:27]: > The second issue is abuot the zope restart for each zope modules installed: > refer to bug #134516. > I think that we can do something better using apt.conf option. [1] > My idea is that the prompt should be: > > Would you like to restart zope: > (1) After module package unpacking. > (2) Once, at the end of the installation process. > (3) Manually. > > If option (2) is selected, zope modules packages may touch a file [2] on > postinst to state that user wants zope to be restarted only once at the end; > zope, that installed an apt configuration file [3], may uses the apt option > [1] to restart itself checking for packages file [2]. > > I'd appreciate any opinion, hint and so on. Just as a sidenote: First of all, mea culpa for being a bad maintainer of the zope package in the last few months. Part of it was due to the Python transition (though doko deserves a lot of credits for most of the work), part of it was due to real world issues. Thankfully, some of these real world issues gave me some ideas about what is broken in the design of the Zope packages ;-) I already told a few of you in private emails about my plans for refactoring the Zope package. One issue is that I'd like to split the sample Zope instance (Data.fs.in) off from the Zope framework; i.e. installing the "zope" package should *not* set up and configure any Zope server instance, but only install the framework. Instead, there would be a new package (e.g. "zope-simple" or "zope-example") which would install and (deb)configure a single sample Zope instance. That should make it much easier to setup more complicated scenarios like a server running multiple Zope instances or ZEO. Furthermore, it would help the autobuilders with build-depends (although I'm thinking about splitting off a zope-dev package with headers at al). If all works well, I might have a working prototype of this NG Zope packages at the end of the next week. I would appreciate comments regarding this redesign. Regarding the restart issue: What you suggest, Luca, sounds really good to me (I tried to achieve something similiar by hacking with debconf: http://lists.debian.org/debian-devel/2001/debian-devel-200107/msg01870.html, but your attempt sounds more relaxed). A remaining problem are .zexp products. I don't see any solution at all for packaging them so that they get automatically and safely upgraded (I could even say: I don't see any reason for packaging them ;-). Gregor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#125857: gadfly: Fix for postinst
Package: gadfly Version: 1.0-7.1 Severity: normal Tags: patch Please make the postinst script more robust by including the following patch. Thanks, Gregor --- gadfly.postinst Wed Dec 19 21:18:22 2001 +++ gadfly.postinst.new Wed Dec 19 21:22:29 2001 @@ -5,13 +5,14 @@ # PACKAGE=gadfly -DIRLIST="/usr/lib/python2.1/site-packages" +PYVER=2.1 +DIRLIST="/usr/lib/python$PYVER/site-packages" case "$1" in configure|abort-upgrade|abort-remove|abort-deconfigure) for i in $DIRLIST ; do -python -O /usr/lib/python2.1/compileall.py -q $i -python /usr/lib/python2.1/compileall.py -q $i +/usr/bin/python$PYVER -O /usr/lib/python$PYVER/compileall.py -q $i +/usr/bin/python$PYVER /usr/lib/python$PYVER/compileall.py -q $i done ;;
