Section of the sendmail manual page
Hi everyone,
Of the 13 packages in sid providing mail-transport-agent, four come with a sendmail(1) manual page, while the remaining eight ship with sendmail(8) (citadel-mta has neither of them; I’m going to open a serious bug after receiving some replies to this mail). I could barely care less under most circumstances, but it does make maintainer scripts for sendmail wrappers longer by two dpkg-divert lines. Which section of the manual do you think sendmail belongs in? I don’t have a strong opinion on this; it can act as a daemon process as well as an ordinary program started by an MUA. I’d personally go with sendmail(8) to file fewer bugs (it’s the traditional choice, too). Cheers, -- Michael Schutte <michi@uiae.at> |
Section of the sendmail manual page
pe, 2008-08-29 kello 20:42 +0200, Michael Schutte kirjoitti:
> sendmail(8) (citadel-mta has neither of them; I’m going to open a > serious bug after receiving some replies to this mail). I don't think a missing manual page is a serious bug. > Which section of the manual do you think sendmail belongs in? I don’t > have a strong opinion on this; it can act as a daemon process as well as > an ordinary program started by an MUA. I’d personally go with > sendmail(8) to file fewer bugs (it’s the traditional choice, too). /usr/sbin/sendmail is, most importantly, a command line API for sending e-mail, which user agents and other software can and do use. For this role, I think section 1 is most appropriate, and section 8 is also fine. /usr/sbin/sendmail can also be a daemon that provides a mail transport agent. For this role, section 8 seems like the only choice. Thus, I think the right section is dependent on how the package uses the /usr/sbin/sendmail it provides, but if you insist on the same section being used everywhere, then it's 8. I do not see it as a problem for different packages to provide the manual page in different sections. But I may be missing something, and if so, please elaborate. -- To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
Section of the sendmail manual page
Lars,
On Fri, Aug 29, 2008 at 09:50:23PM +0300, Lars Wirzenius wrote: > pe, 2008-08-29 kello 20:42 +0200, Michael Schutte kirjoitti: > > sendmail(8) (citadel-mta has neither of them; I’m going to open a > > serious bug after receiving some replies to this mail). > > I don't think a missing manual page is a serious bug. Of course it isn’t… > > Which section of the manual do you think sendmail belongs in? I don’t > > have a strong opinion on this; it can act as a daemon process as well as > > an ordinary program started by an MUA. I’d personally go with > > sendmail(8) to file fewer bugs (it’s the traditional choice, too). > > /usr/sbin/sendmail is, most importantly, a command line API for sending > e-mail, which user agents and other software can and do use. For this > role, I think section 1 is most appropriate, and section 8 is also fine. > > /usr/sbin/sendmail can also be a daemon that provides a mail transport > agent. For this role, section 8 seems like the only choice. > > Thus, I think the right section is dependent on how the package uses > the /usr/sbin/sendmail it provides, but if you insist on the same > section being used everywhere, then it's 8. Yup, that’s about my stream of thought as well. > I do not see it as a problem for different packages to provide the > manual page in different sections. But I may be missing something, and > if so, please elaborate. No, it isn’t much of a problem, it’s just a little inconsistency I came across recently. Working on a sendmail wrapper, I noted that setting up a diversion on /usr/share/man/man8/sendmail.8.gz and installing a replacement was not enough to hide the original sendmail’s manpage in all cases. So I have a choice between using two diversions or changing some packages. -- Michael Schutte <michi@uiae.at> |
| All times are GMT. The time now is 08:46 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.