From owner-freebsd-questions Sun Apr 30 23: 8:24 2000 Delivered-To: freebsd-questions@freebsd.org Received: from waltz.rahul.net (waltz.rahul.net [192.160.13.9]) by hub.freebsd.org (Postfix) with ESMTP id 82B5737B519 for ; Sun, 30 Apr 2000 23:08:16 -0700 (PDT) (envelope-from dhesi@rahul.net) Received: by waltz.rahul.net (Postfix, from userid 104) id 82C1899F31; Sun, 30 Apr 2000 23:08:13 -0700 (PDT) To: freebsd-questions@freebsd.org Subject: Re: Why does PORTS SUCK so BADLY!? Newsgroups: a2i.lists.freebsd-questions References: X-Newsreader: NN version 6.5.1 (NOV) Message-Id: <20000501060813.82C1899F31@waltz.rahul.net> Date: Sun, 30 Apr 2000 23:08:13 -0700 (PDT) From: dhesi@rahul.net (Rahul Dhesi) Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth Wayne Culver writes: >> That is my question.=A0 It seems the idea behind ports is trapped in the >> 70's.=A0 They hardly work and many times get errors about "file not >> found" or something equally annoying.. so I have to go in and screw >> with it "by hand" which is no problem for me.. but the newbies are >> another story. Once I ran make lynx and it said I had to have X11 >> installed.=A0 What a crock.. another fine example is openssl ...=A0 It >> wants the useless RSAREF crap.=A0 What a crock!=A0... >I only have a couple of things to say to you about the ports >collection. First off, you must be doing something wrong because I have >NEVER had any of these problems.... I have encountered the following problems with ports: - Doing "make" in some ports directories requires X-Windows to be installed even though the software will be used from the command line only. It's possible to suppress this with various defines or environment variables, but these are poorly documented or not dcoumented at all. An extreme example of this is python, which pulls in tk, which pulls in X-Windows. (If you type "make" in the python ports directory and walk away, and come back two hours later, you will find the machine grinding away compiling the entire XFree86 ports tree.) Another example of an unexpected dependency is that when you build 'expect', it requires the man page 'expectk.1' to exist, which does not if you already built tcl without tk. (Thus you will get a "file not found" error.) In general the ports tree only grudgingly tolerate the existence of machines on which X-Windows and related software is not installed. - "make package" in one more ports ignores value of 'PREFIX', and tries to install or deinstall in the default directory tree. (I no longer remember which one(s).) - Suppose a long "make" that invokes multiple package dependencies aborts with an error for some reason. After this there is no way of fixing the problem and restarting the make, without first doing a complete "make clean" individually in each ports directory. I encountered this while building one of the Apache ports. - Various make options (e.g. "make extract", "make package", "make deinstall", "make reinstall") are poorly documented. - Ports differences for US residents vs non-US residents are generally not clearly documented. - During a "make" or "make install", sometimes instructions are printed to the screen that quickly scoll up and are lost. An attempted work-around for this is to do something like "make >& make.log" or "make install >& install.log". But if you do this, then some ports will not build because they ask questions during the build process. - Some choices presented during the make are not documented anywhere. Thus the user must browse through the various directories and read all the scripts, and try to decode the logic, before building the port. Or the user must guess, and he will often guess wrong. For example, when building the XFree86 3.3.6 port, the user is asked if he wants to use PAM, and the default that is presented ('yes') causes the resulting port to disallow logins. - When a directory within the /usr/ports tree has been replaced with a symlink, and if the destination of the symlink contains a colon in its name, some builds fail. Probably it's because some commands (not sure which) interpret a colon in a filename to mean that the file lies on a remote machine. Fix: Avoid using colons in filenames and directory names. - The reasons for the various patches included with ports are generally not documented. This is a problem if a patch includes a critical security fix, because the user then does not know for sure whether a published security-related problem is or is not fixed in the port. A casual look at the patch might persuade a user that a certain security problem has been fixed in the port, but the fix might be for some other older security problem. The user will proceed to use the port with the security problem still there. Now some of you will respond by saying that I should file a bug report, and/or write the documentation and submit it. Yes I should, but the above comments are not addressed to you. Rather, these comments are addressed to the people who reason that if they have not encountered a certain problem, then it must not exist. (Not just Kenneth Wayne Culver above, but also everybody else who replied with answers of the type "you must be doing something wrong because I have never had any of these problems....".) -- Rahul Dhesi (spam-filtered with RSS and ORBS) See my ORBS faq: http://www.rahul.net/dhesi/orbs.faq.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message