On Saturday 21 April 2001  2:02 pm, Frederick Bruckman wrote:
> On Sat, 21 Apr 2001, Chris Gilbert wrote:
> > Optional dependancies will allow the ability to have extra features
> > turned on if you have that package installed.  Eg kdepim2 would enable
> > kpilot if you've got misc/pilot-link installed, something that not
> > everyone would want but some might.  It might also assist in cases of
> > circular dependancies.
>
> How? Please explain.

How to which part?  Perhaps I'm unusual (a freak :) in that I generally 
compile all my own packages, but I've noted that some packages don't enable 
some options which they could, eg kdepim2 doesn't enable kpilot, probably 
because the person who created that package doesn't have a palm pilot.  
However I do, and I'm sure others do, so I do want kpilot enabled, so the 
choice is do we make everyone install the pilot-link even if they don't need 
it, or allow people to build there own versions which do enable it.

> > How do we handle binary packages?
> > My suggestion would be that if an optional package was found on the build
> > system then it becomes a dependancy for that binary package.  This will
> > complicate doing bulk builds, but it depends on how many optional
> > dependancies there are.  However to handle this it would perhaps be worth
> > having a global flag saying ignore optional dependancies.
>
> Having "indeterminate" binary packages would really suck. New users
> would ask, "How come package foo gets installed on i386, but not on
> {sparc,m68k,alpha}.  Aren't {sparc,m68k,alpha} fully supported?"

As most binary packages are put up by people who've done a bulk build, it 
would make sense to have an option that disabled all optional dependancies, 
or did the complete opposite and added them to the default build list 
(however I can see cyclic dependancies creeping in there)

> As it is, it's possible to install "kde" and "gnome" from binary
> packages only about half the time -- it depends on how conscientiously
> the builder updated all the dependencies. This looks to me like one
> more thing to go wrong.

In which case the builder is at fault for not providing all the binary 
packages they used.  There room for human error in all that we do, this 
shouldn't make it any worse.  I'd expect anyone doing package builds to have 
actually removed all there existing packages so that all those that are 
needed are actually built and packaged up.

> > OPTIONAL_DEPENDS +=	pilot-link>=0.9.3:../../misc/pilot-link:message about
> > what this extra package will add.
> >
> > If it finds something in the OPTIONAL_DEPENDS section installed it adds
> > it to DEPENDS.  If it doesn't find the package it can optionally display
> > the message as to what functionality would be added.
> >
> > If an optional package needs to set options to enable the functionality
> > some way of detecting this might be needed eg:
> > .if ${OPT_pilot-link}
> > 	CONFIGURE_ENV+=  -enable-palm-link
> > .endif
>
> This could all be accomplished within the existing framework...
>
> .include ../../mk/bsd.prefs.mk
>
> PILOT_USES_PALM_LINK?=	YES
> .if defined(PILOT_USES_PALM_LINK) && ${PILOT_USES_PALM_LINK} != "NO"
> DEPENDS+=		pilot-link>=0.9.3:../../misc/pilot-link
> CONFIGURE_ENV+=		--enable-palm-link
> .endif


Why should everyone have to have palm-pilot stuff installed if they've not 
got one?  Do we look like linux :)

Would every package that can enable something optional be done this way?  
Some packages currently do there own thing, eg gnucash uses --without-motif, 
someone may want it to use motif.

Other examples, kdemultimedia2 can use ogg-vorbis if it finds it (which it 
doesn't as it doesn't look in /usr/pkg)  some people might want that, others 
might not, however currently the decision is made by the person who made the 
package not by the user, as the packager has to draw the line somewhere at 
how much stuff they should have in by default, by making it optional it 
becomes the users choice of "ooh if I install X it'll be used in Y cool"  
rather than my linux friend has feature X in Y but why doesn't netbsd.

> .include ../../mk/bsd.pkg.mk
>
> with an appropriate entry in mk.conf.example.
>
> The above would turn it on by default. The rule is to build the
> packages as full-featured as possible, unless there's a good reason
> not to, like if the dependency introduces a more restrictive license.

Why have it on, not everyone might want that feature.

Chris