From owner-freebsd-hackers Tue Apr 14 22:22:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22838 for freebsd-hackers-outgoing; Tue, 14 Apr 1998 22:22:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA22619; Wed, 15 Apr 1998 05:20:14 GMT (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA21968; Wed, 15 Apr 1998 01:19:35 -0400 (EDT) Date: Wed, 15 Apr 1998 01:19:35 -0400 (EDT) From: "Matthew N. Dodd" To: Peter Wemm cc: Satoshi Asami , phk@FreeBSD.ORG, committers@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Come on guys, close a PR or two, will ya ? In-Reply-To: <199804150507.NAA24706@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG All solveable problems. A more robust packaging system will solve most of these. On Wed, 15 Apr 1998, Peter Wemm wrote: > - Man page names in PLIST's.. The other BSD's don't gzip the pages, that > causes PLIST problems. PLIST.os.arch or something similar if you want a direct bug ugly solution. > - Shared library naming strategies. We're going to have this soon when we > hit elf too. Makefile.os.arch.inc in the base port dir. " " > - Dependencies on the base system. For example the p5-* ports would have > trouble with OpenBSD's use of perl5 in the base tree. We will probably > have this problem too some time. The other BSD's have things like libwrap > and identd in the base tree as well, NetBSD has no perl at all, so things > like /usr/bin/perl can't automatically be used. > > - Locations of system critical files. OpenBSD at least puts security and > system critical etc files in /etc where they belong rather than patching > everything to /usr/local/etc. They do not put these files in PLIST's so > that they survive a pkg_delete prior to a new version being installed. A better packaging system/management system solves these. Debian has most of these problems solved (thought I'm in no way advocating we adopt their tools; they just have some good ideas) > - Naming issues. DESCR files etc refer to FreeBSD by name, patch files > patch in "FreeBSD" into things, etc. Again, OS and arch specific differences must be supported in a more meaningful way. Once this is solved doing release specific modifications to ports will be possible. > - Political issues. Who runs the show? Do all NetBSD/OpenBSD committers > automatically get commit rights to the ports tree the same way the FreeBSD > folks do? Presumably the ports tree would move to a seperate CVS > repository with seperate commit and access lists? I would envision a separate ports project which would imply this sort of seperation. > On a seperate machine to minimize the political friction of having all > parties having accounts on the same machine? How can ports be tested > cross-platform? Three build/ test machines, one for each OS, available > to all ports commiters? What about pre-release ports tree freezes? - > those inconvenience 2 parties. With a separate project the ports tree wouldn't be tied to any specific release. (Or rather should not.) > This probably means branching the tree for each release by each OS. Check out how debian manages this problem. > - Policies like 'the ports tree supports 2.2-stable and not -current' > become nonsensical as the inter-os differences are generally far greater > than the 2.2/3.0 differences. You're missing the big picture. This is one of the problems that would have to be solved in order to support the other BSDs. > - Probably a zillion other things. Indeed. You've spelled out a number of things that I was aware of but unable to convey in a meaningful manner. > Much of this could probably be dealt with by bsd.port.mk, but where the > PLIST is concerned there is a problem as there doesn't seem to be an easy > way of doing some sort of pre-processing of the PLIST to counter things > like manpage compression policy. IMHO, this already is a problem as we > can't package things with no man page compression ourselves. It may be that the current way of doing this is showing its shortcomings. > Don't get me wrong, I'd love to see it happen, but the question is.. is > there sufficient willpower and energy to make it work and put out the > fires during the teething process? This is an issue that will have to be solved some time. If/When FreeBSD supports the Sparc, Alpha and whatever else we will face these same issues. We can start dealing with them now and enlist the help of others who stand to benefit greatly (ever seen NetBSD's ports tree? ick) from the venture. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message