Recommended Dependencies

DJ Lucas dj at
Sat Aug 29 12:37:39 PDT 2009

Randy McMurchy wrote:
> DJ Lucas wrote these words on 08/29/09 11:20 CST:
>> Required:  Package will not build/install/work without it.
> There has been in the past a slightly different look about the above.
> Keep in mind the "Run Time" thing we have hashed out a million times.
> If a package needs a dependency only at run-time, then we annotate
> that.
Yes.. Package will not build and/or install without it. :-)
>> Recommended:  Package looses significant functionality without it or 
>> (new) causes issues with other packages if omitted.
> We see the same on all cases except this one. This is where it has
> always been "Editor's Choice". And I'm not a big fan of that one. I
> look at it that if an Optional package dependency can be identified
> in a short parenthetical note that it provides significant functionality,
> then that is the way to do it.
> Example:  Gimp right now. libjpeg and libtiff are Recommended. And I
> have to agree with that, using DJ's "significant functionality" rule.
> But that sort of conflicts what I just said in the previous paragraph.
> The difference I see is that if we don't put these two libraries as
> Recommended, then we put the switches to disable them on the configure
> command line.
> This is what I don't like. A user that has the libraries installed but
> simply cuts and pastes our instructions. That user just built a Gimp
> that doesn't support basic images. Hence, recommended.
Well, that particular installation was probably doomed from the start.  
Then again, that is exactly what we are trying to battle even for 
ourselves.  If we could account for everything, the instructions for 
even a simple package would be ridiculously long (something to the 
effect of 'if [ -f /usr/lib/]; then CONFFLAGS="--with-jpeg 
$CONFFLAGS"; else CONFFLAGS="--wihtout-jpeg $CONFFLAGS"; fi' just for 
libjpeg, imagine somthing like gstreamer plugins).  I sincerely hope 
that none of our readers are so ignorant in that they would completely 
ignore the surrounding text.  Fortunately, our target audience is above 
average users who can read and who can make educated decisions, that is, 
if we provide enough information to make an educated decision.
> So indeed there is "Editor's Choice". It just has to be used prudently.
Yeah, no black and white here, but now it's "Community Choice".  With at 
least some agreement among editors and dev participants, we can avoid 
the medium-greys. :-)  A summary of this thread would probably make a 
good addition to the Editor's Guide.

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the blfs-dev mailing list