From owner-freebsd-ports  Thu Jun 29 05:30:45 1995
Return-Path: ports-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id FAA22827
          for ports-outgoing; Thu, 29 Jun 1995 05:30:45 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA22821
          ; Thu, 29 Jun 1995 05:30:41 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id FAA02104; Thu, 29 Jun 1995 05:30:32 -0700
Date: Thu, 29 Jun 1995 05:30:32 -0700
Message-Id: <199506291230.FAA02104@silvia.HIP.Berkeley.EDU>
To: rgrimes@gndrsh.aac.dev.com
CC: ports@freebsd.org, jkh@freebsd.org
In-reply-to: <199506281609.JAA09532@gndrsh.aac.dev.com> (rgrimes@gndrsh.aac.dev.com)
Subject: Re: My wishlist
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: ports-owner@freebsd.org
Precedence: bulk

 * > (2) Strip all binaries, compress all manpages (conditional to
 * >     /etc/make.conf)
 * Thank you, I think I was the one who sniveled about this one not
 * looking at /etc/make.conf :-)

Yep, it was you.  You still want to help? :)

 * > (3) Convert subdir Makefiles into "SUBDIR += port1" "SUBDIR += port2"
 * >     format instead of "SUBDIR = port1 port2 port3"
 * 
 * Why?  The current /usr/src tree does not do this, and it may slow
 * down make slighly more vs a \ continued line.  I don't see the 
 * advantage to this, is there one?

Hehe.  You said this is "Another Good Idea (TM)" when I proposed it a
while ago.  The idea is it's easier to add/delete things, harder to
screw up the order, and I want to eventually turn this into something
like (combined with (11) further down the list):

 BROKEN     += a_broken_port
 SUBDIR     += a_good_port
 RESTRICTED += cryptic_port
 SUBDIR     += great_port
 SUBDIR     += some_port
 RESTRICTED += what_a_jerk

(Note the rhs is in alphabetical order)

 * Egads, you want to know how to test 300 software packages that very
 * in complexity from simple to very complex.  Gee, that one would make
 * a year long project for a CS student in software engineering/QA, and
 * might even qualify for a masters thesis :-)

Well, I'm not trying to do something as complicated as that, but
anything would be better than status quo (which is, basically, "huh? 
whatever")....

 * Rather than ping, traceroute and then filter the data based on timing
 * and hop count.  Traceroute gives a much better set of statistics, and
 * is reasonably fast if run with -n so that DNS reverse lookups do not
 * slow it down.  Use hop count to break close (say within 20%) ties in RTT.
 * This would be one major cool thing to have working, IMHO!!!

Hmm, let me see if I can come up with a shell script or something to
do this....

 * > (8) DISTDIR -> DISTPATH
 * > 
 * >     I know Jordan's been needling my backside about this for a long
 * >     time, I simply can't come up with a good idea on how to handle it
 * >     in bsd.port.mk....
 * for i in ${DISTPATH}; do 
 *   if [ -f ${i}/${DISTFILE}...

It's ${DISTFILES}, note the plural.  Also, do we want to do the check
on every stage (fetch, checksum, extract)?  If not, we'll have to
remember the dir/file pair for every component of ${DISTFILES}.

Also, if it's not on the system, we need to put it into the first
writable directory.  Etc., etc., too many complications, and mk macros
are just not powerful enough to write these stuff without major
hackery....

 * > (10) Better handling of info files, info/dir

 * Agreed, but not caused so much by us as the design of info and 
 * the ``dir'' file.  

I know, but it's still very confusing to the users.... ;)

Satoshi