replacing the standard mta with qmail (Re: Question about dselect)
Hi,
On Sun, 7 Nov 1999, Bastard Operator From Hell wrote:
> I recently replaced exim with qmail as that is what I have to administer at
> work and I would rather glitch something up at home vs on-the-job.
There is some additional effort required to install qmail, you have to
compile your own debs, as the licence prohibits distributing those.
Because of this, dselect doesn't know about the qmail debs in the same way
as it knows about the regular debs from the debian archive.
> Slight problem though, when I removed exim, dselect also wanted to remove
> all of my MTA and mail related packages (i.e.: af, anacron, at, elm-me+,
> fmirror, logrotate, mailx and mutt), so of course, I exited the Select
> phase of dselect with the "Q" option to force it to ignore the depends.
You should not use dselect to replace your mta. Dselect is a great tool
to manage dependencies, but in this case, you really want to _work_around_
dependencies, making dselect the wrong tool for this particular job.
You can not (easily anyway[1]) use dselect to install qmail, because there
is no archive containing pre-built qmail.deb.
[1] Okay, so you can actually use dselect with non-regular archives, but
it's not worth doing in this case anyway.
This is what you want to do:
1. get qmail source and build a deb:
apt-get install qmail-src
cd qmail-src-*
fakeroot debian/rules binary
cd ..
( 1a. maybe do the same for ucspi-tcp-src:)
2. carefully remove the old mta, while disregarding other packages
dependencies:
dpkg --force-depends --remove exim
3. install the qmail.deb (perhaps also ucspi-tcp*deb):
dpkg --install qmail*deb
That's all there should be to it. Now, you can continue using dselect for
all you daily updates and standard package installations and removals. The
only package that it cannot update automatically is qmail, because there
is no qmail.deb in the archive.
If you decide however to keep qmail-src.deb installed on your system, you
will be able to notice every update of that package. You can then rebuild
a local qmail.deb and install it manually. This time, there are no
"force" flags needed to dselect.
Notice that when you run dselect, it will show the "installed" status of
the qmail package, but it knows only the installed version, not the
available version, because there is no "official archive" version of the
qmail.deb. For the same reason, dselect classifies the package as
"Obsolete/local Unclassified packages without a section". This is nothing
to worry about.
> Imagine my surprise when deselect informed me that it would be removing
> the packages that I _thought_ I had forced to stay installed.
Are you sure that wasn't _apt_ telling you that? Apt has a mind of its
own (which is usually a good thing) about resolving dependencies and
conflicts. It makes similar calculations about package dependencies as
dselect, because it has to know in what order best to install the
downloaded packages.
Most of the time, this behaviour is a feature. In your case, it
interferes with what you're trying to do. At least dselect will let you
override dselect's opinion of packages to be (de)selected, apt is more
strict in these things and won't be overridden AFAIK[2].
[2] Then again, I didn't read all of the apt documentation that
meticulously yet, YMMV
> Now, this doesn't hurt me too badly as I am capable of manually installing
> software, but it does mean that the automatic check for critical updates, etc.
> that dselect does are now unavailable on this system.
This is unnecessary when done right. You only lose the ability to
automatically update qmail.deb. All other packages (including
qmail-src.deb) will still be upgradable using dselect, as usually.
> I'm posting to the devel list since this seems to be a problem with dselect
> rather than operator error (or at least the RTFM on the man pages, HOWTO's and
> user/devel list archives didn't turn up anything usefull).
I'm adding debian-user to the cc:, since I figure this isn't the first
time and probably isn't the last time either that dpkg/dselect/apt confuse
people, not in the least because many aspects aren't very well documented.
Cheers,
Joost
Reply to: