Re: ITP: mta-dummy
On Wed, Dec 05, 2001 at 09:04:54PM +0100, Wouter Verhelst wrote:
> On Wed, 5 Dec 2001, Adam McKenna wrote:
> > I'd like to discuss the creation of an mta-dummy package.
>
> [... makes installing an MTA from source easier ...]
>
> > If anyone can think of a serious reason that this shouldn't be in the archive
> > (i.e., other than that you think it's silly, or the standard Packages file
> > bloat argument), please speak up, otherwise I'll upload this in a week or so.
>
> Why only an mta-dummy package? Why not a also httpd-dummy, ftpd-dummy,
> ircd-dummy, and whatnot?
I'm only interested in mta-dummy. If someone else wants to package up
ftpd-dummy or httpd-dummy, that's fine with me too. However, I believe MTA
is a special case because:
1) Many unrelated packages depend on mail-transport-agent. This is for the
most part not true of the others you mentioned. Generally, things depending
on httpd are related to httpd or run under httpd. Things depending on m-t-a
are just packages that need to send mail.
2) Several high-priority packages depend on mail-transport-agent. Again,
most programs depending on (e.g.) httpd or ftpd are optional add-on packages
such as kwuftpd or analog. This makes it much harder to remove the currently
installed MTA without breaking dependencies, because you'd have to remove
things like at and cron.
> If you want to install from source, I think it's better to either
> - Use the Debian source package (if the reason you want to install from
> source is not that you think that the Debian package sucks)
Debian hasn't yet packaged every MTA on the planet.
> - Create a dummy package yourself, locally. There is a package in the
> archive that allows you to do just that; if I understood correctly, all
> you have to do was to create a controlfile, run a script over it, and you
> have a package with the wanted Depends and/or Provides.
As I said in my original message, I've done this already. The purpose of
this package would be to make things easier for others.
I've heard some good arguments against this, and I am taking them into
consideration. From what I've read, it doesn't seem like this package
would be breaking policy, but if someone thinks otherwise please let me
know.
--Adam
--
Adam McKenna <adam@debian.org> <adam@flounder.net>
Reply to: