Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!violet.berkeley.edu!jkh From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Newsgroups: comp.os.386bsd.development Subject: Re: .../ports and ported software. Date: 15 Sep 1994 02:09:42 GMT Organization: University of California, Berkeley Lines: 45 Message-ID: <358ad6$aje@agate.berkeley.edu> References: <356v48$8ut@shore.shore.net> <3575v3$nkk@agate.berkeley.edu> <357ooj$qsv@shore.shore.net> NNTP-Posting-Host: violet.berkeley.edu In article <357ooj$qsv@shore.shore.net>, Robert Withrow <witr@rwwa.com> wrote: >In article <3575v3$nkk@agate.berkeley.edu>, jkh@violet.berkeley.edu (Jordan K. Hubbard) writes: >|> Rather than making a central repository of diffs, what I did instead was >|> to make each port an encapsulation of the procedure required to make >|> it run under FreeBSD. > >Well, I aplaud what is no-doubt a nice piece of configuration control >sleight-of-hand, but I wonder if this system can deal with the problems >that stimulated this post. > >Namely, if I have some version related to, but not identical to one of >your ``ports'', what help does your port stuff give? For example, if >I have version+1 or perhaps an experimental version of the original code >what do I do. You look at the previous port and you'll see any and all patches, scripts or FreeBSD-specific configuration files necessary for making it work. A good example of this are the irc or libncurses ports. Of course, if the previous port didn't REQUIRE anything fancy to work (as was the case with the tcl port you mailed me about), then obviously there aren't going to BE any patches and you'll be on your own should tcl 9.0 come out fully re-written in C++ and requiring massive intervention. Not a whole lot we can do about that! In the cases where changes were required, however, it's now a LOT easier to see what was required. You see the patches in the patches/ directory and any scripts that need to do non-patchable changes in scripts/, it doesn't get much more straight-forward than this! The old system just gave you a port to look at and you were required to diff it yourself, hoping that the resulting diff didn't represent lots of other weird things like directory moves or file renaming. Conversely, should such things be required in a 2.0 port, it'll be in an obvious scripts/configure file that does the moving and renaming so as to keep the patches as simple as possible. I think you need to look at more of the ports before passing judgement! :-) >And, what do you send back to the developers of the ported package, if >not just plain-old diffs? You *are* sending back the changes, arent you? Of course! Look at the /usr/ports/GUIDELINES file - this is recommended quite strongly! The ultimate goal with any port is to finally have just a Makefile and a pkg directory containing the binary package information! Jordan