Re: cvs commit: ports/games/vegastrike-data Makefile

From: Pav Lucistnik <pav_at_FreeBSD.org>
Date: Sat, 31 May 2008 10:56:08 +0200
Alexey Dokuchaev pÝ╣e v so 31. 05. 2008 v 08:27 +0000:
> On Fri, May 30, 2008 at 11:31:51AM +0200, Pav Lucistnik wrote:
> > Alexey Dokuchaev p??e v p? 30. 05. 2008 v 09:26 +0000:
> > > On Thu, May 29, 2008 at 09:37:50PM +0000, Pav Lucistnik wrote:
> > > > pav         2008-05-29 21:37:50 UTC
> > > > 
> > > >   FreeBSD ports repository
> > > > 
> > > >   Modified files:
> > > >     games/vegastrike-data Makefile 
> > > >   Log:
> > > >   - Disallow this from pointyhat builds; we don't need to repackage 520 MB of
> > > >     game data and load it on all our mirrors
> > > 
> > > Why not follow the way it's done in e.g. games/nexuiz port and alike??
> > > Looks like it gives more control to user.
> > 
> > This will not affect end-users in any way. PACKAGE_BUILDING is defined
> > in and _only_ in pointyhat environment.
> > 
> > End users can still `make package' and all that. Unless I'm missing
> > something?
> 
> Ah, OK, so if I simply want to prevent building what can be called
> "official" package (which will be put on ftp.freebsd.org and mirrors), I
> should check for PACKAGE_BUILDING and set IGNORE (or maybe NO_PACKAGE is
> better?).  

NO_PACKAGE means the port is built, but never packaged. So here, where
the problem is as early as fetch phase, you need IGNORE.

Generally you don't want to disallow package from pointyhat unless you
have a very very good reason.

> If there is some inherent problem with building a package
> (not just to reduce payload on our DVDs), like legal issues with the
> software, I just use NO_PACKAGE.  Am I getting this right?

Porter's Handbook is very verbose on this topic -
http://www.freebsd.org/doc/en/books/porters-handbook/porting-restrictions.html


-- 
Pav Lucistnik <pav_at_oook.cz>
              <pav_at_FreeBSD.org>
Fairy tales do not tell children that dragons exist. Children already
know dragons exist. Fairy tales tell children that dragons can be
killed. -- G. K. Chesterton

Received on Sat May 31 2008 - 09:23:19 UTC