(Very) bogus package dependencies

Paul Schmehl pauls at utdallas.edu
Thu Dec 6 20:41:30 PST 2007

--On December 6, 2007 10:32:51 PM -0500 Alex Goncharov 
<alex-goncharov at comcast.net>, Alex Goncharov <alex-goncharov at comcast.net> 
>| It looks like an ordinary indirect dependency.
>| The drivers as well as the xorg-server all require 'hal'.
> Yes:
> --------------------
> $ pkg_info -r xf86-video-radeonhd-*
> ....
> Dependency: hal-
> Dependency: xorg-server-1.4_3,1
> --------------------
>| 'hal' depends on 'cdrtools'.  (It may be that the drivers only
>| depend on xorg-server,
>| As for why 'hal' requires 'cdrtools' I have no idea, but there is
>| probably some reason for it.
> And this is precisely the second of the two questions I have in mind:
> 1. (Purely technical): Where is this originally recorded?
>    I don't see anything applicable in the port's directory:
> --------------------
># find /usr/ports/sysutils/hal -type f| wc -l
>    567
># find /usr/ports/sysutils/hal -type f -exec grep -Hn 'cdrtools' {} \;|
># wc -l
>      0
> --------------------

That's because you're not looking in the right place.  Open the Makefile 
for hal and you find:

Now, why cdrtools is required to build the port is a question that is 
answered by going to /usr/ports/Mk/bsd.port.mk and reading the section on 
USE_CDRTOOLS.  Then continue to trace from there, and you will find that 
hal won't build without some file or files that are installed by cdrecord. 
(No, I'm not going to do that for you.)
>    But I do see it in `/var/db/pkg':
> --------------------
># find /var/db/pkg/hal- -type f -exec grep -Hn 'cdrtools'
># {} \;
> /var/db/pkg/hal- cdrtools-2.01_6
> /var/db/pkg/hal-
> DEPORIGIN:sysutils/cdrtools --------------------
>    So, is it that a port maintainer creates `/var/db/pkg/PKG/*' files
>    by hand?  Based on individual ideas?  Not on really "must-to-have"
>    things, like dependencies on shared libraries?
Absolutely not!  /var/db/pkg/portname is built by the ports system based 
upon how the port is built.  Most maintainers (including me!) would have 
no clue what's in the CONTENTS page without looking at it, because we have 
"nothing" to do with its creation (other than the fact that we created the 

> 2. (Conceptual): How reasonable are these dependencies?
I doubt seriously any port maintainer just picks dependencies willy-nilly. 
They're chosen because the source code docs cite them as requirements 
and/or because the port won't build without them.

>    In this case, `/usr/sbin/burncd' is all I need to burn CD's.  I
>    have no practical reason to have `cdrtools' on my computer.
Of course you do.  Otherwise it wouldn't be there.

>    Why would the "Hardware Abstraction Layer for simplifying device
>    access" depend on a specific set of "CD/CD-R[W] and ISO-9660 image
>    creation and extraction tools" -- on this set and not on another?
It most likely doesn't.  It depends upon a file or files that are 
installed by cdrtools.

Look at one of my ports, security/barnyard.  It depends on snort.  Why? 
Because that's the only thing it's designed to work with.  Without snort, 
there's no reason to have barnyard on your system.  Another port, 
devel/byacc, has no dependencies at all.  Another one, 
security/sguil-server, has multiple dependencies, some because they're 
required for proper operation, others because the port won't build without 
those libraries.

If you want to spend time figuring all that out, be my guest, but the 
maintainers have already done all that work for you, and the committers 
have verified that it's required and that it works as expected.

That's the beauty of ports.

Paul Schmehl (pauls at utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas

More information about the freebsd-ports mailing list