Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Aug 1997 00:59:54 -0400 (EDT)
From:      Chuck Robey <chuckr@glue.umd.edu>
To:        Bruce Gingery <bruce@home.gtcs.com>
Cc:        freebsd-ports@hub.freebsd.org
Subject:   Re: ports/4304: Recommendation re. Ports Collection
Message-ID:  <Pine.BSF.3.96.970815005750.326A-100000@Journey2.mat.net>
In-Reply-To: <199708142349.RAA28160@home.gtcs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Aug 1997, Bruce Gingery wrote:

You know, I don't want to comment on the quality of the suggestion, I want
to comment on putting a suggestion like this into the GNATS problem data
base.  It really seems to be blatant abuse of the system.  No wonder folks
complain about things getting lost in the bug list; it's all full of
things that simply don't have an obvious way to close them.


> 
> >Number:         4304
> >Category:       ports
> >Synopsis:       Recommendation re. Ports Collection
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       medium
> >Responsible:    freebsd-ports
> >State:          open
> >Class:          change-request
> >Submitter-Id:   current-users
> >Arrival-Date:   Thu Aug 14 16:50:00 PDT 1997
> >Last-Modified:
> >Originator:     Bruce Gingery
> >Organization:
> Advanced Integrators, LC
> >Release:        FreeBSD 2.2.1-RELEASE i386
> >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 :))))
> 
> 
> >Audit-Trail:
> >Unformatted:
> 
> 

----------------------------+-----------------------------------------------
Chuck Robey                 | Interests include any kind of voice or data 
chuckr@eng.umd.edu          | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770         | I run Journey2 and picnic, both FreeBSD
(301) 220-2114              | version 3.0 current -- and great FUN!
----------------------------+-----------------------------------------------




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970815005750.326A-100000>