Date: Tue, 2 May 2000 05:12:53 -0700 (PDT) From: asami@freebsd.org (Satoshi Asami) To: ports@freebsd.org Subject: ports projects Message-ID: <200005021212.FAA46737@silvia.hip.berkeley.edu>
next in thread | raw e-mail | index | archive | help
Well, people keep talking about documents and directions so let me try
something for the ports team. Here is a list of things I would like
to see happen, or in the process of doing, or am aware that someone is
working on, that is important for the ports collection as a whole.
Basically it's some stuff from the wishlist I've made several years
ago (thankfully most of them are gone now! :) plus many other recent
developments.
Comments and additions most welcome. By the way, "Good stuff!" means
I'm aware of the work but have taken a look at it only a couple of
times, and deeply regret that I don't have enough time to work closer
on it but would like you guys to keep working because I think it's a
very good idea. Apologies to anyone who has a worthy project I have
overlooked due to inattention.
@ PLIST cleanup (status: in progress)
As mentioned yesterday, I changed the package build scripts to
print out a list of files and directories that aren't listed in
PLIST. I've fixed a couple of glaring ones that bloat up the
whole listing because it appears so many times (libtool, info/dir,
zh_TW.big5), and now it's up to the maintainers or other
interested people to do the cleanup. You can find the listing at,
for instance,
http://bento.FreeBSD.org/errorlogs/3-latest-logs/extras.html
I already see some spectacular blowups (crosssco/elm/tex...) which
I hope will be fixed soon. :)
@ Multi-level categories/reducing directory count (status: (slowly)
in progress)
We have discussed this a while ago on the ports list. The idea is
to have a variable-depth tree of categories (Editors/Emacs,
Japanese/InputMethods/Canna,...). Since this requires a repo-copy
of the entire tree, we have also discussed changing the ports
structure to have less directories (pkg/* -> pkg-*, etc.) to
reduce the "too many small files and directories" problem of the
ports tree that pessimizes the peformance on conventional
filesystems (which is all we have, unfortunately).
I'm planning to restart the discussion soon.
@ Real upgrade support (status: in progress)
The first step of splitting PKGNAME to PORTNAME/PORTVERSION has
been completed. Now we need to decide exactly how lay out the
files in /var/db/pkg/${PORTNAME}, and implement hooks in
bsd.port.mk/pkg_* to get it to work. NetBSD might be of help.
Anyone who wants to take a look at the pkg_* source? ;)
@ Splitting up XFree86 (status: in limbo)
I'd like to split up the XFree86 port so we can automatically
build packages for individual components (imake, lib, bin, various
servers, etc.), and have true dependencies to them, and use these
as the recommended method for installing XFree86 instead of the
XFree86-supplied tarballs. This will get rid of a lot of special
casing from the package build process and also reduce the amount
of problems people have with ports only needing X libs
automatically pulling in the entire XFree86, etc.
However, the person who has been working on this the last couple
of years (Taguchi-san) has been missing. I'm trying to locate him
but will appoint a replacement if I can't find him in the next
couple of days. The current plan is to split up XFree86-4 as well
as create a bunch of XFree86-3 server ports ASAP, and then switch
the default dependency to XFree86-4 based ports after the release
of 3.5. (XFree86-3 server ports will remain in the tree as long
as the XFree86 project supports it so don't worry about your video
chip.)
@ PREFIX-cleanness (status: (slowly) in progress)
There are PREFIX-clean fixes committed every day, but I'd like to
make a master list to help people identify which ports are
culprits.
I'm thinking about modifying the package build script so that the
mid-week (the runs that build RESTRICTED ports and everything
since it's not for FTP) builds will run with LOCALBASE and X11BASE
set to someplace else. The XFree86 situation is a holdup though,
since I need to be able to generate the XFree86 tarball on the fly
to have the X11BASE change take effect.
@ Modular file stowage (status: none)
I'm thinking about storing all files from a port in its own
subtree (like /usr/pkg/${PKGNAME}) and making a symlink tree from
${PREFIX}. This will allow people to test new versions while
still having the old version around, and quickly switching back if
there is something wrong with the new one (we need to provide a
script to switch back the links, which is not hard to implement).
The previous item (PREFIX-cleanness) is a requisite for this to
work.
@ Security audit (working: kris and asami)
I'll create a list of ports that install setuid/setgid/world
writable direectories so Kris can use it for his ports security
audit project.
@ Portlint rewrite (working: mharo)
http://people.FreeBSD.org/~mharo/portlint3/
Good stuff!
@ Freshports (working: dan@langille.org)
http://www.freshports.org/ports.php3
Good stuff!
@ portconf (working: nbm)
http://people.FreeBSD.org/~nbm/portconf/
Good stuff!
@ Optional dependencies (working: reg)
http://people.freebsd.org/~reg/
Good stuff!
@ New packaging system (status: in limbo)
Jordan has been threathening to replace the current packaging
system for years (it was supposed to arrive with 3.0 :) and even
has some working code snippents but the project has ground to a
halt due to the developer leaving and also not enough attention
paid by us. Anyone want to pick it up?
@ Fetching distfiles from the nearest master site (status: none)
It really bothers me when I do a make on bento 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. Any
good ideas? "ping" all the MASTER_SITES and sort them? I know
that NetBSD has a MASTER_SORT that allows you to specify
preferences depending on domain name (.edu before .com, etc.), but
network topology has little to do with domain names (for instance,
there are too many .org's with miserable connectivity to the US
due to them being located in Timbuktu) so I don't think it will
work well.
Of course, for most people, this is just a matter of setting
MASTER_SITE_OVERRIDE to a mirror site near you. So maybe I
shouldn't worry about it too much, the package building machine is
one of the very rare cases where this is not desirable.
@ Better handling of restrictions (what if depended port is
illegal, is interactive, etc.) during package build (status: none)
Right now what I do is either (1) build all packages with
NO_RESTRICTED and/or FOR_CDROM defined, which will cause those
that depend on such ports not being built, or (2) build everything
and then delete stuff that are not allowed with
clean-{restricted,for-cdrom}. The latter has a side effect of
deleting too many distfiles -- for instance, if there is a port
that uses emacs-20.6.tar.gz plus a crypto distfile and have
RESTRICTED set for the latter, clean-restricted will remove
emacs-20.6.tar.gz as well.
@ Fuzzy dependency lists (status: none)
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. NetBSD might be of help.
@ Find a replacement for myself so I can retire (status: none)
Any takers? ;)
Satoshi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005021212.FAA46737>