From bruce@home.gtcs.com  Thu Aug 14 16:49:36 1997
Received: from home.gtcs.com (home.gtcs.com [206.54.69.238])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA21964
          for <FreeBSD-gnats-submit@freebsd.org>; Thu, 14 Aug 1997 16:49:33 -0700 (PDT)
Received: (from bruce@localhost)
	by home.gtcs.com (8.8.5/8.8.5) id RAA28160;
	Thu, 14 Aug 1997 17:49:09 -0600 (MDT)
Message-Id: <199708142349.RAA28160@home.gtcs.com>
Date: Thu, 14 Aug 1997 17:49:09 -0600 (MDT)
From: Bruce Gingery <bruce@home.gtcs.com>
Reply-To: bruce@home.gtcs.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Recommendation re. Ports Collection
X-Send-Pr-Version: 3.2

>Number:         4304
>Category:       ports
>Synopsis:       Recommendation re. Ports Collection
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    portmgr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 14 16:50:00 PDT 1997
>Closed-Date:    Fri Aug 30 14:18:33 PDT 2002
>Last-Modified:  Fri Aug 30 14:18:33 PDT 2002
>Originator:     Bruce Gingery
>Release:        FreeBSD 2.2.1-RELEASE i386
>Organization:
Advanced Integrators, LC
>Environment:

		FreeBSD - all versions

>Description:

	  Currently, some ports are 20k, others are 8megs BEFORE
	extraction, and may require 20 megs to build and install.
	With varying net speeds, a 20k wonder is something that most
	people can just invoke a make on at any time, even if a fetch
	needs to be done before the make progresses. 

	   FreeBSD users are running systems with all kinds of 
	configurations, from massive servers like the ftp server at
	CDROM.com, to 4meg-RAM i486 wonders with a couple hundred
	megs of disk.

	   While the old standard of ``don't FTP during business hours''
	at the target site is far less observed today than it used to
	be, most people on modem connections don't really want to start
	an 8-meg download during Friday prime-time, unless they have
	a really primo connection to the net.

	   CDROM.com could also benefit from this change to port and
	package info when building new CD's.

	  Also why not an ``installed'' target?  This one is nearly there
	now.  Of course this one is easy as a shell alias.

>How-To-Repeat:

	N/A

>Fix:
	
     bsd.ports.mk target additions  (target / description)

	   fetch-size-get  (depends on fetch)
		creates a ${FILESDIR}/SIZES file equivalent to the md5 file
		with the size of each component.

	   size-of-fetch
		reverse-grep ${FILESDIR}/SIZES excluding pseudos below

	   make-size-get (depends on install)
		Well, if BUILD_SIZE is defined, merely uses it, else
		uses a ``just installed'' du -s ${WRKSRC} or ${WRKDIR}
		appends to ${FILESDIR}/SIZES with pseudo filename
		``size-of-make''

	   size-of-make
		Reports ${BUILD_SIZE} if defined, else
		grep's size-of-make from ${FILESDIR}/SIZES

	   install-size-get (depends on package)
		Uses ${INSTALL_SIZE} if defined, else
		runs wc -c piped from tar -xzf, appends to 
		${FILESDIR}/SIZES with pseudo filename ``size-of-install''

	   size-of-install
		Reports ${INSTALL_SIZE}, if defined, else
		greps size-of-install from ${FILESDIR}/SIZES

	   package-size-get (depends on package)
		Uses ${PACKAGE_SIZE}, if defined, else
		does a wc -c of the package tar-ball,
		inserts package distribution size into ${FILESDIR}/SIZES

	   size-of-package
		Reports ${PACKAGE_SIZE} if defined, else
		greps size-of-package from ${FILESDIR}/SIZES

	   port-size-get - depends on clean
		Uses ${PORT_SIZE} if defined, else
		does a du -s on ${.CURDIR}, replaces in ${FILESDIR}/SIZES
		hence with a couple of runs, will be accurate, even though
		it will change its own value.  puts in a psudo-filename
		``size-of-port''.  Perhaps it should automatically run
		twice.

	   size-of-port
		Reports ${PORT_SIZE} if defined, else
		greps size-of-port from ${FILESDIR}/SIZES - if compared
		with a current du gives a simple indication of possible
		modification of a port's content.

	   size
	   size-to-install-port
	   size-to-install-package
		cat ${FILESDIR}/SIZES, or better yet, invokes a Perl
		script that spits out the details with totals.  The
		``size'' target merely invokes the other two.

	   size-to-build
		check missing dependencies, include THEIR size-to-build's
		in a summary report.  This is the one to be used the most
		by end-users and administrators.  This one is the most
		work to implement, of course, and because of the target
		system state dependency, should't be aliased into a
		Makefile variable.

	   check-sizes
		Compares size values within the Makefile stated above
		with the sizes reported in the ${FILESDIR}/SIZES values.
		This is very like the ``checksum'' target, except that
		it would insure that the a make install, package, and
		clean have been executed.

	   installed:
		pkg_info `make package-name`

	   dwimnwis:
		Takes a bare directory and a URL and creates a completed
		port :))))


>Release-Note:
>Audit-Trail:

From: Tim Vanderhoek <hoek@hwcn.org>
To: Bruce Gingery <bruce@home.gtcs.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-ports@hub.freebsd.org
Subject: Re: ports/4304: Recommendation re. Ports Collection
Date: Thu, 14 Aug 1997 21:09:08 -0400 (EDT)

 On Thu, 14 Aug 1997, Bruce Gingery wrote:
 
 >      bsd.ports.mk target additions  (target / description)
 > 
 > 	   fetch-size-get  (depends on fetch)
 > 		creates a ${FILESDIR}/SIZES file equivalent to the md5 file
 > 		with the size of each component.
 > 
 > 	   size-of-fetch
 > 		reverse-grep ${FILESDIR}/SIZES excluding pseudos below
 
 Hm.  The other possibility would be to simply have authors note
 in pkg/DESCR that X port has a large distfile.
 
 Your short description doesn't take into account possible port
 dependencies.  
 
 What I could see being useful is a recursive size-fetch which
 determines the total size of all necessary downloads in order to
 do a complete install.  This is probably a bit more involved than
 it sounds...
 
 
 > 	   make-size-get (depends on install)
 > 		Well, if BUILD_SIZE is defined, merely uses it, else
 > 		uses a ``just installed'' du -s ${WRKSRC} or ${WRKDIR}
 > 		appends to ${FILESDIR}/SIZES with pseudo filename
 > 		``size-of-make''
 
 Ugh.  I wouldn't like to see this.  The actual software's make
 targets may create and delete temporary files during build.
 Additionally, the build size may vary from machine to machine
 where each has a different local (or system) configuration.
 
 
 > 	   install-size-get (depends on package)
 > 		Uses ${INSTALL_SIZE} if defined, else
 > 		runs wc -c piped from tar -xzf, appends to 
 > 		${FILESDIR}/SIZES with pseudo filename ``size-of-install''
 
 Can be easily derived from package size.
 
 
 > 	   package-size-get (depends on package)
 > 		Uses ${PACKAGE_SIZE}, if defined, else
 > 		does a wc -c of the package tar-ball,
 > 		inserts package distribution size into ${FILESDIR}/SIZES
 
 This isn't worthwhile.  I feel to lazy to outline the reasons.
 :)  Just imagine the possible circumstances where you would use
 it and compare to the alternative of manually checking.
 
 
 > 	   port-size-get - depends on clean
 > 		Uses ${PORT_SIZE} if defined, else
 > 		does a du -s on ${.CURDIR}, replaces in ${FILESDIR}/SIZES
 > 		hence with a couple of runs, will be accurate, even though
 > 		it will change its own value.  puts in a psudo-filename
 > 		``size-of-port''.  Perhaps it should automatically run
 > 		twice.
 
 Is this worthwhile?  The ports collection as a whole is pretty
 small.  Unless there are some monstrous patches, the size of the
 port itself is generally insignificant.  If there are monstrous
 patches, it's generally just as easy to check the file sizes of
 ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/games/tvp-0.9.7/patches
 as it is to download and read
 ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/games/tvp-0.9.7/pkg/SIZES.
 
 
 > 	   size-to-build
 > 		check missing dependencies, include THEIR size-to-build's
 > 		in a summary report.  This is the one to be used the most
 
 This logically belongs with make-size.  I disapprove of
 make-size, though.  Accordingly, I comment on its theoretical
 existance in my response to fetch-size.  Just so you know.  :-)
 
 
 
 --
 Outnumbered?  Maybe.  Outspoken?  Never!
 tIM...HOEk
 

From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
To: steveg@comtrol.com
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: ports/4304: add our port to FreeBSD base 
Date: Thu, 14 Aug 1997 18:16:46 -0700

 > How do I submit our request to have our port added to FreeBSD.
 > I have the our port working, just need to get it added.
 
 You should have attached it to this PR? :)
 
 					Jordan
Responsible-Changed-From-To: freebsd-ports->asami 
Responsible-Changed-By: obrien 
Responsible-Changed-When: Tue Jul 28 11:05:50 PDT 1998 
Responsible-Changed-Why:  
Satoshi is the bsd.port.mk man. 
Responsible-Changed-From-To: asami->portmgr 
Responsible-Changed-By: will 
Responsible-Changed-When: Wed Apr 4 00:58:19 PDT 2001 
Responsible-Changed-Why:  
Over to new maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4304 

From: "David W. Chapman Jr." <dwcjr@inethouston.net>
To: <FreeBSD-gnats-submit@freebsd.org>, <bruce@home.gtcs.com>
Cc: "Will Andrews" <will@FreeBSD.org>
Subject: Re: ports/4304: Recommendation re. Ports Collection
Date: Fri, 8 Jun 2001 15:51:39 -0500

 Can this be closed....
 
 Release
 FreeBSD 2.2.1-RELEASE i386
 
 
State-Changed-From-To: open->closed 
State-Changed-By: kris 
State-Changed-When: Fri Aug 30 14:12:45 PDT 2002 
State-Changed-Why:  
Superceded by other PRs which contain patches 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4304 
>Unformatted:
