Date: Sun, 30 Apr 2000 23:08:13 -0700 (PDT) From: dhesi@rahul.net (Rahul Dhesi) To: freebsd-questions@freebsd.org Subject: Re: Why does PORTS SUCK so BADLY!? Message-ID: <20000501060813.82C1899F31@waltz.rahul.net> References: <freebsd-questions.Pine.GSO.4.21.0004251750060.2099-100000@rac6.wam.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Kenneth Wayne Culver <culverk@wam.umd.edu> 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 <dhesi@email.rahul.net> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000501060813.82C1899F31>