Bug#468569: [Pkg-mailman-hackers] Bug#468569: no way to escape mailman/queue_files_present
tags 468569 pending thanks On Monday 8 December 2008 16:06, Marcin Owsiany wrote: On Mon, Dec 08, 2008 at 03:20:30PM +0100, Thijs Kinkhorst wrote: Hi Marcin, On Tue, November 25, 2008 14:04, Marcin Owsiany wrote: Obviously this is only useful for reinstalling the same version, or for disaster recovery, but I still think this is worth including. I have prepared a patch (attached). Before applying, do a: svn mv debian/preinst debian/preinst.in I hated to make the script a preprocessed file, but I could not find any better way of determining the currently installed version in preinst. Thank you for your work. However, I'm not enthusiastic to include it. It's onyl useful in a small majority of cases, but adds quite some complexity in the overall packaging... Can you be more specific? This use case (unattended disaster recovery) is important for me, so I can work on improving this patch. I was not enthousiastic specifically about the rewriting of preinst, which I still consider to be hackish. However, I haven't found a better way to implement the desired functionality, so I have included it. Thank you for your help in this. Furthermore I have also turned the debconf note into an option to continue the installation if the administrator thinks he can live with the results. I think this should satisfy most cases. Of course the best solution would still be to actually detect whether there would be incompatibilities between the two versions, but we do not have a real solution to that currently. cheers, Thijs pgpEWAjp46qwg.pgp Description: PGP signature
Bug#468569: [Pkg-mailman-hackers] Bug#468569: no way to escape mailman/queue_files_present
* Thijs Kinkhorst: Furthermore I have also turned the debconf note into an option to continue the installation if the administrator thinks he can live with the results. I think this should satisfy most cases. Yes, that's fine with me. The magic version file doesn't seem to cover my case of accidental removal because AFAICS, the file disappears when the package is deinstalled. Of course the best solution would still be to actually detect whether there would be incompatibilities between the two versions, but we do not have a real solution to that currently. Upstream could put a version number in the .pck files themselves (assuming that they are Python pickled objects, and that Python is generally backwards-compatible in this area). It should be rather straightforward to check those files for compatibility. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468569: [Pkg-mailman-hackers] Bug#468569: no way to escape mailman/queue_files_present
Hi Marcin, On Tue, November 25, 2008 14:04, Marcin Owsiany wrote: Obviously this is only useful for reinstalling the same version, or for disaster recovery, but I still think this is worth including. I have prepared a patch (attached). Before applying, do a: svn mv debian/preinst debian/preinst.in I hated to make the script a preprocessed file, but I could not find any better way of determining the currently installed version in preinst. Thank you for your work. However, I'm not enthusiastic to include it. It's onyl useful in a small majority of cases, but adds quite some complexity in the overall packaging... Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468569: [Pkg-mailman-hackers] Bug#468569: no way to escape mailman/queue_files_present
On Mon, Dec 08, 2008 at 03:20:30PM +0100, Thijs Kinkhorst wrote: Hi Marcin, On Tue, November 25, 2008 14:04, Marcin Owsiany wrote: Obviously this is only useful for reinstalling the same version, or for disaster recovery, but I still think this is worth including. I have prepared a patch (attached). Before applying, do a: svn mv debian/preinst debian/preinst.in I hated to make the script a preprocessed file, but I could not find any better way of determining the currently installed version in preinst. Thank you for your work. However, I'm not enthusiastic to include it. It's onyl useful in a small majority of cases, but adds quite some complexity in the overall packaging... Can you be more specific? This use case (unattended disaster recovery) is important for me, so I can work on improving this patch. -- Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468569: [Pkg-mailman-hackers] Bug#468569: no way to escape mailman/queue_files_present
On Mon, Jul 28, 2008 at 08:01:52PM +0200, Thijs Kinkhorst wrote:
Hi Marcin,
On Friday 29 February 2008 17:03, Marcin Owsiany wrote:
I am currently preparing an installation of mailman on our system. In
order to provide durability of the processed messages, we are going to
arrange for /var/lib/mailman to be located on a block-level replicated
filesystem. Thus, if the box crashes, we will just mount the safe
filesystem on a fresh one and rebuild it (install packages and apply
configs).
However the current mailman's preinst makes it problematic, as it bombs
out if there are any queue files present. My guess is that it should be
safe to install the same version of the software as the one which
created the queue files? In that case it would really help if there was
a way to override this check in some way.
Yes, this check could be improved (it's now too wide-ranging, at least it's
safe but can be very inconvenient). However, the mailman team is currently
not very well staffed.
If you or anyone else experiencing trouble with this can come up with a patch
that improves this test's behaviour I'd gladly consider it.
I had a look at the mailman upstream UPGRADE documentation as well as
some bugs and reports on mailing list. My conclusion is that at this
point it won't be safe to allow any upgrades with the queue files in
place. The only safe thing would be precisely my use case: allow exactly
the same version to be installed as the one previously installed.
Obviously this is only useful for reinstalling the same version, or for
disaster recovery, but I still think this is worth including.
I have prepared a patch (attached). Before applying, do a:
svn mv debian/preinst debian/preinst.in
I hated to make the script a preprocessed file, but I could not find any
better way of determining the currently installed version in preinst.
It seems to produce a valid .deb file, although I have not tested
actually installing the package.
--
Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
--- debian/preinst.in (revision 572)
+++ debian/preinst.in (working copy)
@@ -16,14 +16,32 @@
#DEBHELPER#
-# make sure the qfiles directory is empty.
-if [ -d /var/lib/mailman/qfiles ] \
- [ $(find /var/lib/mailman/qfiles -type f | wc -l) -ne 0 ]; then
-# uh-oh.
+abort_install()
+{
db_fset mailman/queue_files_present seen false || true
db_input critical mailman/queue_files_present || true
db_go
exit 1
+}
+
+# make sure the qfiles directory is empty.
+if [ -d /var/lib/mailman/qfiles ] \
+ [ $(find /var/lib/mailman/qfiles -type f | wc -l) -ne 0 ]; then
+# Check if the queue files were created by the same version as the one we're about to install
+if [ -r /var/lib/mailman/.version ]; then
+ # First check the stamp file.
+ # It is more general because it will show the previous version in the
+ # case that /var/lib/mailman is on permanent storage (e.g. a SAN) and
+ # we are being installed for the first time.
+previous_version=$(cat /var/lib/mailman/.version)
+else
+# Fall back to reading dpkg-provided argument (in case previous version did not leave the stamp file)
+previous_version=$2
+fi
+if [ @VERSION@ != ${previous_version} ]; then
+# we don't know which version the files are from
+abort_install
+fi
fi
exit 0
--- debian/rules (revision 572)
+++ debian/rules (working copy)
@@ -4,6 +4,7 @@
package=mailman
PACKAGE=$(package)
+VERSION=$(shell dpkg-parsechangelog | awk '$$1 == Version: {print $$2}')
include /usr/share/quilt/quilt.make
@@ -25,6 +26,7 @@
build: patch build-stamp
build-stamp: Makefile debian/po/templates.pot
$(MAKE)
+ sed 's,@VERSION@,$(VERSION),g' debian/preinst.in debian/preinst
touch build-stamp
debian/po/templates.pot: debian/templates
@@ -47,6 +49,7 @@
[ ! -f Makefile ] || $(MAKE) distclean
rm -rf build-stamp Makefile debian/ucffiles debian/mailman.postinst.ucf
rm -f debian/mailman.postrm.ucf
+ rm -f debian/preinst
dh_clean
chmod +x debian/{prerm,postinst}
@@ -101,6 +104,9 @@
# link it back to /var/lib/mailman/templates
dh_link etc/mailman var/lib/$(package)/templates
+ # note the current version to avoid aborting on same-version
+ # reinstallations - see the preinst script
+ echo $(VERSION) debian/mailman/var/lib/$(package)/.version
# move the pending subscriptions database so it doesnt overwrite the
# old one when installing
signature.asc
Description: Digital signature
Bug#468569: [Pkg-mailman-hackers] Bug#468569: no way to escape mailman/queue_files_present
Hi Marcin, On Friday 29 February 2008 17:03, Marcin Owsiany wrote: I am currently preparing an installation of mailman on our system. In order to provide durability of the processed messages, we are going to arrange for /var/lib/mailman to be located on a block-level replicated filesystem. Thus, if the box crashes, we will just mount the safe filesystem on a fresh one and rebuild it (install packages and apply configs). However the current mailman's preinst makes it problematic, as it bombs out if there are any queue files present. My guess is that it should be safe to install the same version of the software as the one which created the queue files? In that case it would really help if there was a way to override this check in some way. Yes, this check could be improved (it's now too wide-ranging, at least it's safe but can be very inconvenient). However, the mailman team is currently not very well staffed. If you or anyone else experiencing trouble with this can come up with a patch that improves this test's behaviour I'd gladly consider it. cheers, Thijs pgpE1UWOUI2ay.pgp Description: PGP signature
