[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

qmail



Subject: Posting rejected - please read and agree to mailing list rules.

> Date: 26 Nov 1996 21:56:38 -0000
> Message-ID: <19961126215638.1083.qmail@earth.orbits.com>
> To: debian-devel@lists.debian.org
> Cc: eichin@cygnus.com
> From: moth@debian.org
> Subject: qmail
> 
> I think I have a solution for the qmail problem.
> 
> (1) Make a package qmail-install_0.93_1 which requires gcc, netbase,
> dpkg-dev, and anything else needed.  This package should include the
> directory /var/qmail/src/qmail-0.93/debian/ populated with
> relevant files, as well as a /usr/sbin/qmail-install and probably a
> /var/qmail/src/Makefile with targets like:
> qmail-0.93.tar.gz:
> 	(echo cd pub/software; echo get $@) | ftp -in koobera.math.uic.edu
> Or, maybe not a makefile -- see (4).
> 
> (2) the qmail-install script should retrieve, and build qmail,
> populate a .deb file for a qmail-local package, install the package
> and probably delete the deb package (to avoid giving the implication
> that we're making a .deb file for distribution purposes).
> 
> (3) The Makefile should have an option for cleaning up binaries, but
> probably a more common technique will just be to remove the
> qmail-install package (which should automatically run make clean
> during prerm).
> 
> (4) The script should bail out with a hint on any errors during build.
> For example, if tar doesn't succeed after ftp, maybe the underlying
> source package has been upgraded at koobera, or maybe it's just
> network problems.  For example, dpkg can't successfully install
> qmail-local while another dpkg session is running.
> 
> (5) postinstall for qmail-local should run a script to configure qmail
> for basic mail service.
> 
> (6) this doesn't solve the long-term issues of the uid/gid problem.
> Then again, that problem may be just an artifact of qmail's
> beta-release status.  I don't think we're doing the wrong thing here.
> 
> (7) I don't like the idea of using sudo here, but it may be the best
> option.  I think this kind of mechanism should (a) let the user examine
> the script to be run (b) allow the user to perform the steps manually,
> and (c) not leave any latent permissions around that could be used to
> do something suprising later on.  However this whole issue is probably
> best left for debian 1.3 or later.
> 
> -- 
> Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: