(Very) bogus package dependencies
youshi10 at u.washington.edu
Fri Dec 7 15:42:56 PST 2007
On Dec 7, 2007, at 7:41 AM, Paul Schmehl wrote:
> --On Friday, December 07, 2007 00:18:15 -0500 Alex Goncharov <alex-
> goncharov at comcast.net>, Alex Goncharov <alex-goncharov at comcast.net>
>> I won't dispute the word "beauty" here -- I like the system very
>> But coming from some eight years of using Debian, I am still
>> about the underling mechanics of ports.
>> Your answers definitely help -- thank you!
I'm not sure about you, but I rather like not having 5~10 variants of
the same package for every single option available at build-time :).
> Any time you see USE_FOO= bar in a Makefile, the answer to what
> does that mean will be in /usr/ports/Mk/ somewhere. So grep
> USE_FOO in /usr/ports/Mk/* and you'll find where it appears. Then
> you can read the file and usually figure out what that means. You
> may then have to go read Makefiles for the ports to which it refers
> (in the case of cdrtools, cdrecord) and try to figure out why
> *that* port is required for "your" port to build.
> As maintainers, the first thing we have to do is read the
> requirements for the software and make sure those dependencies are
> built as well. So, for example, if a new port I'm working on
> requires that libdir is installed, I have to figure out whether it
> is or not, and if not, how I get it installed. Whenever possible,
> we try to use the port macros (USE_FOO), but if not, we have to use
> BUILD_DEPENDS to require that some other port is installed before
> ours begins the build.
Correct. The option was required at build-time and is a requirement
for running the package (RUN_DEPENDS), which means that unfortunately
it's required for installation too.
> There are some wonderfully talented and highly knowledgeable people
> working behind the scenes to make sure all this stuff works in
> harmony, so I don't ask why, I just make sure my ports work as
Indeed. There's a lot of work put in by a lot of pkg/ports
maintainers to ensure that stuff works out of the box with as little
work / maintenance knowledge on the end-user portion as possible, and
in the long run not having to keep track of a billion different
options and/or other 'useless' information is the correct way to go
> Paul Schmehl (pauls at utdallas.edu)
> Senior Information Security Analyst
> The University of Texas at Dallas
More information about the freebsd-ports