cvs commit: ports/games/stonesoup Makefile distinfo pkg-descr pkg-plist ports/games/stonesoup/files patch-AppHdr.h patch-makefile patch-rltiles__Makefile

[Alexey Dokuchaev]

On Sun, Aug 08, 2010 at 01:20:03PM -0700, Doug Barton wrote:
> On 08/08/2010 12:37, Rene Ladan wrote:
> > Actually there is nothing wrong with having SDL support in OPTIONS, I
> > merely followed the PR. If you can convince the maintainer to revert
> > factoring out SDL support, I'll be happy to make the corresponding commit.
> 
> Personally I think we need a lot more slave ports. OPTIONS are great for
> people building the ports themselves, but if we're going to move to a
> model dominated by packages then more slave ports are a good thing.

Slave ports can be good enough solution in certain cases (particularly,
when slave ports itself carries enough logic inside its Makefile), but
most of the time they just alter some knobs in the master, hardly more.
Just having ability to specify non-default WITH_FOO at the expense of new
directory, new Makefile with a dozen lines *irrelevant* to WITH_FOO,
extra line in ../Makefile and modules -- it looks ugly even for one
port, yet you say "we need a lot more slave ports".

We definitely do not need slaves, most often it is actually a mistake to
use them; as for "model dominated by packages", take a look at RPM
specfiles: they support subpackages way better than what we do now with
our slaves.  There are many things to learn from Linux distros about
binary packages, but at this point it is fairly obvious that subpackage
metainformation should be encoded in original Makefile similar to how
%package directive works with RPM, not in the slave port with lonely
Makefile a few lines long.

We abandoned pkg-comment in favor of COMMENT and have PLIST_FILES for
short package lists exactly for that reason: it is better to have that
stuff close together, unless it is big enough to warrant its own file.

./danfe