Bug in ports howto question

[Allan Bowhill]

On  0, Roman Neuhauser <neuhauser at bellavista.cz> wrote:
:Please obey the MFT header. For information on how to may your fellow
:mutters happy see http://www.mutt.org/doc/manual/manual-3.html#lists

Ok, let's see if I get it right this time.

(mistake 1: I just chopped the bylines here)

:> :> > I think it's asking too much to require sendmail configuration 
:> :> > expertise from contributing porters. Sendmail configuration is
:> :> > normally relegated to sysadmins that specialize in it.
:> :
:> :    then use a different MTA, one with proper documentation,
:> :    configuration helpers, or digestible config file formats. there's
:> :    plenty of them in ports. qmail bundled documentation contains
:> :    precise description of steps required to produce a nullclient
:> :    configuration, as does postfix documentation.
:> 
:> Thanks. I educated myself on this with the help of Simon Barner, who
:> is doing documentation for the handbook on this problem. And it _is_
:> a problem.
:
:    Been there, got the scars. Actually the problem is not GNATS
:    unavailable for submit with http (try browsing around
:    http://bugs.guug.de/db/pa/lmutt.html - Oh. My. God.) or
:    mx1.freebsd.org requiring one to have a working DNS and MTA
:    configuration. The problem is Sendmail, its config files, its lack
:    of documentation, and finally its position as a default MTA in
:    FreeBSD.

I agree. Sendmail is probably one of the poorest-documented tools out
there. I think they are trying to sell O'Reilly books. Unfortunately,
unlike other platforms, to send and receive mail on FreeBSD, you need to
a little about how mail works. I did not know a lot in this area, before
I started.

After learning a bit, I am left with the impression that internet
mechanisms and standards that support mail are complicated and
somewhat badly-designed. Evolutionary. (too many specialized
protocols, headers, acronyms)

Despite all this, the configuration task is not that bad if you have
good instructions, but in principle, is overkill for submitting
ports. It's a little like trying to do square-foot gardening with a
combine. But if you have the time and documentation, you can get it
to work properly.

The bad part is you don't discover you don't discover all this stuff 
until it's too late, and your resources have been drained.
 
:> :> > The skill sets are mutually exclusive.
:> :
:> :    aha. you can't possess skill in both skiing and driving. the skill
:> :    sets are mutually exclusive. eh?
:> 
:> Yep. Skiiing is not driving, and driving is not skiiing.
:> They require mutually exclusive skill sets.
:
:    Perhaps it's just my poor English (ESL speaker here, beware!) but
:    doesn't "exclude" imply "to prevent the other from existing"? At
:    least the online Merriam-Webster would make me believe so.

No. It just means they are separate entities, not dependent on one
another. You could argue systems administration depends on you ability
to program. You could also argue it doesn't. My problem is with the
definition of systems administration.

Needless to say, you need good systems administration skills to submit
new ports to GNATS if you have a dynamic IP on your development box.

:> This is a problem, becuase the PR was a new port. Now nobody will touch
:> the port becuase it looks too hard to deal with. So it will probably sit
:> in GNATS for 6 months, until someone takes it upon themselves to clean
:> it out. Then, I guess I can re-submit it.
:
:    Just mail gnats-submit@ (or whatever's the correct address) with
:    ports/#YOUR-PR-NR in subject and the correct patch attached.

Yes. That's how I messed up the second submission out of three. Whatever
you do, don't send it as an attachment in outlook express :)

-- 
Allan Bowhill
abowhill at blarg.net

At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.