(Very) bogus package dependencies

[Beech Rintoul]

On Friday 07 December 2007, Garrett Cooper said:
> 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>
> >
> > wrote:
> >> I won't dispute the word "beauty" here -- I like the system very
> >> much.
> >> But coming from some eight years of using Debian, I am still
> >> mystified
> >> 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 expected.
>
> 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 IMHO.

Lets not forget the developers who make up portmgr. They support and 
guide us also keeping the whole project going in the same (relative) 
direction, insuring that all of the ports build and install in the 
same way. This further lessens the burdon on users who "just want it 
to work". They have the unenviable task of actually building close to 
90,000 ports for the new releases. They also actively maintain the 
software that keeps track of all these dependencies. As you have seen 
the dependencies from just one port can become complicated. Imagine 
trying to map all 18,000 ports in the tree. Our system isn't perfect, 
but it's constantly being improved. I'll take our port/pkg system 
over any of the other *nix systems.

Beech 

-- 
---------------------------------------------------------------------------------------
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
---------------------------------------------------------------------------------------