Date: Wed, 28 Jun 1995 02:53:52 -0700 From: asami@cs.berkeley.edu (Satoshi Asami) To: ports@freebsd.org Cc: rgrimes@gndrsh.aac.dev.com, jkh@freebsd.org Subject: My wishlist Message-ID: <199506280953.CAA07974@silvia.HIP.Berkeley.EDU>
next in thread | raw e-mail | index | archive | help
Here are the things I'm thinking of doing between now and 2.2. The
2.1, being the "stable" release, will pick up whatever that is working
good enough at the head of -current.
(1) New categories (www, benchmarks, security, sysutils, emulators)
(2) Strip all binaries, compress all manpages (conditional to
/etc/make.conf)
(3) Convert subdir Makefiles into "SUBDIR += port1" "SUBDIR += port2"
format instead of "SUBDIR = port1 port2 port3"
These aren't very difficult, I already fired up a discussion for
(1) and expect it to be done soon. (2) and (3) is simply a matter
of someone to dive in there and convert all the necessary
Makefiles.
(4) More master sites
We can try to add more "standard" mirror sites (crl.dec.com for
ftp.x.org, gatekeeper.dec.com for prep.ai.mit.edu, etc.), but I
need a lot of help from people. If you have a port that doesn't
have multiple entries in MASTER_SITES, and it's not one of the
well-mirrored groups of software like the ones above, please add
some more sites.
(5) MAINTAINER for every port
Hey, where have people gone hiding? C'mon, it's not like I'm
going to chase you around with a pointed whip in my hand if the
port breaks, so please put your name up there if you are taking
care of a port. You need to "claim" credit for yourself in the
ports world, or Joe users won't know what a great work you've
done! :)
(6) Better and more organized periodic testing
Any ideas?
(7) An ability to fetch from the nearest master site
It really bothers me when I do a make on thud.cdrom.com and it
proceeds to go fetch the stuff from Europe or Japan, when it's
readily available in California in one of the later MASTER_SITES.
The same goes for the people in the other sides of the ponds, I
guess. Any good ideas? "ping" all the MASTER_SITES and sort
them? ;)
(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....
(9) Better handling of dependencies (what if depended port is
illegal, is interactive, etc.)
For instance, if you do a "make" in mule-wnn with BATCH set, it
will go into Wnn and return without doing anything because it
IS_INTERACTIVE. However, this is not an error (otherwise top-down
makes will fail) so bsd.port.mk will happily proceed to compile
mule-wnn, only to blow up in the middle. :<
(10) Better handling of info files, info/dir
There are two directories to start with (/usr/share/info and
/usr/local/info). Also, ports will add *.info files but won't
update the "dir" file, etc. This is a mess.
(11) Add BROKEN and RESTRICTED to bsd.port.subdir.mk
Instead of just having SUBDIR, I want to "officially" support
BROKEN and RESTRICTED in bsd.port.subdir.mk so that it won't be
completely ignored when we're doing a top-down something (like
making an INDEX file).
(12) A better way to handle slight variations (cf. less/colorless)
It's easy to add a "configure" script and make it interactive, but
I'd prefer a batch solution....
(13) Fuzzy dependency lists
Right now, if you try to pkg_add xfig that's compiled with
xpm-3.4e, and you only have xpm-3.4f on your system, it will
barf. Granted some combinations won't work, but there should be a
better way to handle this....
(14) Mega-packages
This is just a matter of someone adding a new item to CATEGORIES
of the relevant ports. However, we already have lots of
subdirectories in /usr/ports, and it might look a little confusing
unless we make it clear it's a mega-package that the user wants to
add everything in it at once, and not a category.
(15) More classes of dependencies
The current framework of EXEC_DEPENDS, LIB_DEPENDS and DEPENDS is
way too raw, and people are complaining about the emacs *package*
pulling in gmake, etc.
Well, that's all I have for now. I'm planning to bring them up later
again, but if you have any suggestions, opinions or additions, feel
free to comment (or go ahead and fix them :).
Thanks....
Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506280953.CAA07974>