Recommended Dependencies

Uwe Düffert dueffert at uwe-dueffert.de
Sat Aug 29 10:49:42 PDT 2009


Hi,

I absolutely agree that it should be explained as to why a dependency is 
regarded as recommended. That information is very valuable to readers.

On Sat, 29 Aug 2009, Randy McMurchy wrote:

> DJ Lucas wrote these words on 08/29/09 11:20 CST:
>> 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.
To me, there is not that much of a difference between those two points of 
view. The key is _significant_. I do not want to get yet another 
feature/packages/dependency recommended just be because the editor likes 
or uses it. Thats just a candidate for "optional". However, as you 
mentioned yourself, there are cases where it is possible to ommit a 
certain feature/switch/dependency, it will build and run, but it is not 
useful.

Gimp without jpeg support seems to be a quite simple example.
There are more tricky ones. In those cases I want people knowing the 
package better than me (a.k.a editors ;-]) to recommend me what 
switches/dependencies to use (like "I dont see any usecase for compiling 
Gimp without jpeg support, so if you want Gimp you almost for sure will 
want jpeg support for it, even if you did not hear about jpeg before"). If 
I know for sure that I will never ever use jpeg, I can just ignore such a 
recommendation. After all, a recommendation is just a featured option with 
an explanation of someone claiming to know it better as to why it is 
recommended.

Uwe



More information about the blfs-dev mailing list