Mutt made me believe that Greg A. Woods wrote:
> [ On Thursday, May 24, 2001 at 20:26:01 (+0200), Thomas Klausner wrote: ]
> > Subject: Re: DEINSTALL scripts for daemon packages
> >
> > Just for the record:
> > In pkgsrc, they REQ files we had have been deprecated for
> > INSTALL/DEINSTALL ones. (i.e. no more support for them in bsd.pkg.mk).
> 
> Hmmm...  that's either very wrong, or very short-sighted, or both.
[...]
> > The support in pkg_* hasn't been removed for historical reasons (you
> > could still have a binary package of one of the four packages that
> > used a REQ file.)
> 
> If the *policy* is to not write more of them then that's either very
> short-sighted, stupid, or both!  ;-)  (and it's an undocumented policy!)

Since you seem to express your feelings about it, let me express mine:
1) Nobody needed it -- we had over 1500 (lots more, but I'm not
exactly sure on the number, so let's just say 1500) packages in pkgsrc
when I removed it, and the _four_ uses that were made of it where
easily replaced by some code in INSTALL (one was actually just a
MESSAGE in disguise). And I haven't run over a package where I would
have liked to have it, and I have looked at a lot of packages, believe
me.

2) 'undocumented policy': I didn't have to remove much text that
explained what to use REQ for. [Perhaps that's a reason that not many
packages used it, if you want. On the other hand, it doesn't seem
anybody else has been missing REQs.]

3) It adds overhead, and INSTALL can be easily used for the same -- no
need to differentiate.

Perhaps I'm missing something, but what's the advantage of splitting
in a 'check' and 'modify' part? Like, can you point to packages where
it really would help?

If a necessary thing, if missing, can be done automatically, it should
be, and if it can't, it doesn't matter if INSTALL tells you so or if
REQ does, does it?

So, in summary: Just use (DE)INSTALL instead.

Bye,
 Thomas

-- 
Thomas Klausner - wiz@danbala.tuwien.ac.at