(Very) bogus package dependencies

[Beech Rintoul]

On Monday 10 December 2007, Paul Schmehl said:
> --On Monday, December 10, 2007 16:33:20 +0200 Andriy Gapon
>
> <avg at icyb.net.ua> wrote:
> >> From a small research it seems that the only thing needed from
> >> cdrtools
> >
> > is isoinfo utility which gets called in FreeBSD-specific code
> > (hald/freebsd/probing/probe-volume.c) like follows:
> > isoinfo -p -i %s
> > And it seems that its only usage is to detect presence of
> > directories named 'VIDEO_TS|VCD|SVCD', so that properties like
> > volume.disc.is_videodvd could be set.
> >
> > Maybe there is a way to write code for this functionality that
> > could be included into hal source code or as a port patch, so
> > that hal doesn't have to depend on cdrtools.
>
> While I have no objections to this particular  suggestion, my
> question would be - where do you stop?  You could easily do this
> for hundreds (if not thousands of ports) that depend upon some
> other port because of one piece of code.
>
> In general. port maintainers follow the guidelines of the software
> developer.  If the developer states that the software depends upon
> cdrtools, then the maintainer is going to include that dependency
> in the port.  Many of us don't have sufficient skill to audit code
> and determine where a dependency could be replaced by some
> additional code.
>
> So, while this might make sense in isolated cases, I don't think it
> scales well.  Furthermore, modern machines generally have enough
> disc space that the addition of a few "unused" ports to include
> necessary code is a small price to pay to distribute the load of
> providing ports over a larger population of volunteers.  (And yes,
> I know not everyone has a modern machine or large discs to work
> with.)

I agree. The ports tree is a moving target. Any time you add custom 
code to a port it puts you (as maintainer) in the position of being 
both developer and maintainer. Frequently building a port will pull 
in dependencies all of which are maintained by different people. We 
already run into the problem where updating port foo requires port 
bar be updated first. Fortunately, there is a lot of cooperation by 
those on the project and  it's rarely an issue. However, adding 
dependent code into the port itself would make this situation an 
absolute nightmare. Instead of maintaining one port, now you're 
maintaining two or more (not to mention license issues). We already 
have ports in the tree which download and extract other ports, but 
only use a specific piece. These tend to all be from the same master 
port or family.  If disk space is a premium common tools like 
autotools can be removed after the port is built, but doing that will 
quickly paint you into a corner where you no longer have the space to 
build. We have options in ports that frequently determine if a 
dependency will be built or not depending on choice. It's up to the 
individual maintainer to include options. Many ports have additional 
options which can be set (or unset) from the command line. We tend to 
include the most common options, but that doesn't mean others aren't 
available. Anyone with interest at this level is strongly encouraged 
to read the port's Makefile before building and installing.

-- 
---------------------------------------------------------------------------------------
Beech Rintoul - FreeBSD Developer - beech at FreeBSD.org
/"\   ASCII Ribbon Campaign  | FreeBSD Since 4.x
\ / - NO HTML/RTF in e-mail   | http://www.freebsd.org
 X  - NO Word docs in e-mail | Latest Release:
/ \  - http://www.FreeBSD.org/releases/6.2R/announce.html
---------------------------------------------------------------------------------------