Add 'optional' or 'recommended' metadata tags to portfile spec.

[c.herbig@…]

There are certain programs that are not actually required for a program to run, but provide additional functionality. I don't think that simply adding them as 'depends_run' ports is a good solution, #39880. For example, Yelp provides a help browser for many Gnome apps, but has many dependencies that, if any are broken, will appear to be problems with the main port to the user. Instead of forcing the user to install yelp as a dependency, it might be better to inform them at install or upgrade time that yelp is a recommended secondary install.

Another example is gnome-themes-standard. Again, it is not at all necessary, but people will expect gnome apps to look a certain way, after seeing screenshots or working with linux systems. Even though this example is more trivial to simply append as a runtime dep, perhaps some people feel that it is not wanted, or are using a different theme.

As such, my proposal is to add one or other of the aforementioned metadata tags, so it would look like this:

recommended_ports   yelp \
                    gnome-themes-standard

and show up to the user after installation is complete as

Recommended supplementary ports:
    yelp                    ${description of yelp}
    gnome-themes-standard   ${description of port}

and let the user decide for themselves.

[cooljeanius (Eric Gallager)]

(for cross-referencing purposes, this is split off from #39886 btw)

[cooljeanius (Eric Gallager)]

Cc Me!

[c.herbig@…]

Replying to egall@…:

(for cross-referencing purposes, this is split off from #39886 btw)

I'm starting to think that just using a variant isn't really the right solution.

[ryandesign (Ryan Carsten Schmidt)]

I like the idea of allowing ports to recommend additional ports. I can think of numerous places where this could be employed. mysql55 could recommend installing mysql55-server. php55 could recommend installing php55-apache2handler. graphviz could recommend installing graphviz-gui.

Presumably the recommendation would not be printed if the recommended port is already installed.

I would like for each recommendation to be accompanied by an explanation. Users would want to know why a port is being recommended. For example, if they were told that yelp is used for accessing help content, and the user has no plans to access the help content, then the user will know they don't need to install it.

[c.herbig@…]

Replying to ryandesign@…:

Presumably the recommendation would not be printed if the recommended port is already installed.

Yeah, that's pretty much what I had in mind.

I would like for each recommendation to be accompanied by an explanation. Users would want to know why a port is being recommended. For example, if they were told that yelp is used for accessing help content, and the user has no plans to access the help content, then the user will know they don't need to install it.

Do you think that simply using the ${description} tag from each recommended port would be satisfactory? It would require that authors use good descriptions. Alternatively, I suppose a description {} keyword could be added to each recommends port line, like variant description {} already does. Or it could be implemented such that if a description {} is not provided, then it defaults to the portfile's description tag.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

I would like for each recommendation to be accompanied by an explanation. Users would want to know why a port is being recommended. For example, if they were told that yelp is used for accessing help content, and the user has no plans to access the help content, then the user will know they don't need to install it.

If suppressing recommendations for already-installed ports isn’t terribly important, can’t this just be handled with notes?