Date: Tue, 2 May 2000 14:47:25 -0400 From: Will Andrews <andrews@technologist.com> To: Satoshi Asami <asami@FreeBSD.ORG> Cc: ports@FreeBSD.ORG Subject: Re: ports projects Message-ID: <20000502144725.A396@argon.blackdawn.com> In-Reply-To: <200005021212.FAA46737@silvia.hip.berkeley.edu>; from asami@FreeBSD.ORG on Tue, May 02, 2000 at 05:12:53AM -0700 References: <200005021212.FAA46737@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 02, 2000 at 05:12:53AM -0700, Satoshi Asami wrote:
> @ 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.
I can make these ports. (I'll volunteer, but it'll be a few weeks before
any such ports come around).
> @ 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.
This can be performed on a blank system by setting PREFIX=/usr/local2 and
seeing whether any files go elsewhere. Perhaps chroot scripts (such as
bento's) can be modified to test this.
> 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.
No problem.
> @ 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.
I would really like this to be implemented, and would be quite glad to
write some of the code. Just to note, this will require a moderate amount
of changes in both bsd.port.mk and pkg_*.
> @ 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.
You can do this by adding a hook in one of bento's scripts to use the same
find(1) call that is executed in the daily scripts.
> @ Portlint rewrite (working: mharo)
>
> http://people.FreeBSD.org/~mharo/portlint3/
>
> Good stuff!
I am going to help mharo with the redesign, and will be contributing
significant amounts of code (hopefully). We hope to get portlint to a point
that it will be possible to integrate it into GNATS. I.e., if someone
submits a port that portlint finds faults with, it will not be filed and
will be returned to the sender.
> @ Freshports (working: dan@langille.org)
>
> http://www.freshports.org/ports.php3
>
> Good stuff!
Yup! :-)
> @ portconf (working: nbm)
>
> http://people.FreeBSD.org/~nbm/portconf/
>
> Good stuff!
>
> @ Optional dependencies (working: reg)
>
> http://people.freebsd.org/~reg/
>
> Good stuff!
As I said in a previous email earlier today, I am hoping to combine both of
these projects; more to come on that.
> @ 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.
This is a similar idea to one I thought of (but I don't necessarily claim
to be the first): master site rotation. There are some exceptions to the
general rule that rotating master sites is a good idea.
This sort of option (as you described) should be regarded as "expensive"
since it will require a few seconds per distfile. Perhaps we could provide
an override for distfiles under X bytes (we'd have to store distfile size).
> @ 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.
check-restricted target that gets performed before pre-fetch; is not
performed on ports that are marked RESTRICTED because it doesn't need to
check for dependencies that are RESTRICTED if the port itself is
RESTRICTED. Then just recursively traverse the dependency listings (we need
a faster way to generate the dependency list) to find any RESTRICTED
dependencies.
> @ 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.
I think that the best way to ensure code compatability would be to rely on
ports/INDEX and set the *_DEPENDS to ${PORTNAME}:${PORTVERSION}, where
${PORTNAME} is the name of the required port and ${PORTVERSION} is the
version of the required port. I haven't looked at NetBSD's ports system
but I believe they use a similar method. In any case,
> @ Find a replacement for myself so I can retire (status: none)
>
> Any takers? ;)
Hmm, I nominate Steve Price. I don't think I have enough experience. :)
I do hope you plan to stay on the team as a ports committer.
Some things I'd like to add:
@ We need a fetch-recursive target in bsd.port.mk. (status: PR ports/12548)
@ Multiple MASTER_SITES for each of ${DISTFILES}, as needed. (status: none)
I'm sure there's plenty more to do that I can't think of.
--
Will Andrews <andrews@technologist.com>
GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+
G++>+++ e->++++ h! r-->+++ y?
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?20000502144725.A396>