Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Apr 1998 01:19:35 -0400 (EDT)
From:      "Matthew N. Dodd" <winter@jurai.net>
To:        Peter Wemm <peter@netplex.com.au>
Cc:        Satoshi Asami <asami@FreeBSD.ORG>, phk@FreeBSD.ORG, committers@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject:   Re: Come on guys, close a PR or two, will ya ? 
Message-ID:  <Pine.BSF.3.96.980415010928.7475Q-100000@sasami.jurai.net>
In-Reply-To: <199804150507.NAA24706@spinner.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980415010928.7475Q-100000>