#39897: Add 'optional' or 'recommended' metadata tags to portfile spec. --------------------------+-------------------------------- Reporter: c.herbig@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by c.herbig@…): Replying to [comment:1 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.

-- Ticket URL: <https://trac.macports.org/ticket/39897#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X

#39897: Add 'optional' or 'recommended' metadata tags to portfile spec. --------------------------+-------------------------------- Reporter: c.herbig@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by c.herbig@…): Replying to [comment:4 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.

-- Ticket URL: <https://trac.macports.org/ticket/39897#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X

#39897: Add 'optional' or 'recommended' metadata tags to portfile spec. --------------------------+-------------------------------- Reporter: c.herbig@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Description changed by larryv@…: Old description:

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.

New description: 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. -- -- Ticket URL: <https://trac.macports.org/ticket/39897#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X

#39897: Add 'optional' or 'recommended' metadata tags to portfile spec. --------------------------+-------------------------------- Reporter: c.herbig@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by c.herbig@…): Replying to [comment:6 larryv@…]:

If suppressing recommendations for already-installed ports isn’t terribly important, can’t this just be handled with notes? It is (in my opinion at least) mainly a matter of convention and tidiness. In my portfile for gnome-chemistry-utils I included a notes section as follows: {{{ notes \ "Recommended supplementary ports: gnome-themes-standard provides the default Gnome Adwaita theme" }}} Although it accomplishes the task of informing the user that there is an additional recommended port, I think it would be better in the end for a standardized method to communicate this information. Additionally, using a data tag would allow things like comment 4, or in the future for MacPorts to offer to proceed with installation of recommended ports if the user agrees, similar to what is done in certain linux distributions. It may also prove useful to search through ports and dependencies based on what they were recommended by.

The reason that I don't think variants are a good solution to this problem is that variants get passed down to dependencies, and later trying to change to a different variant can cause lots of errors with those dependencies who were installed with, and insist on having the previous variant. It can turn into a matter that a user may decide to simply not bother with altogether. -- Ticket URL: <https://trac.macports.org/ticket/39897#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X

#39897: Add 'optional' or 'recommended' metadata tags to portfile spec. --------------------------+-------------------------------- Reporter: c.herbig@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by larryv@…): I don’t think this is worth the development effort if all it does is display a list of maybe-useful ports. That’s what notes are for—to provide a single place to define information that should be displayed after a port has been installed. It’s not the most structured solution, but defining a wholly new Portfile option with special syntax (“description” fields and the like) seems needlessly complex. Likewise, simply giving “recommended” and “optional” labels to different dependencies based on the variants that require them would add complexity without commensurate utility. As far as I’m concerned, the only functionality that merits this is the ability to operate on recommended ports in the same way that we can currently operate on dependencies and dependents. (As you mentioned, many package managers allow for this.) It would probably require a great deal more work than simply adding a new option. The dependency engine would have to be made aware of this new relationship, and the semantics of the relationship would have to be thoroughly discussed. -- Ticket URL: <https://trac.macports.org/ticket/39897#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X

#39897: Add 'optional' or 'recommended' metadata tags to portfile spec. --------------------------+-------------------------------- Reporter: c.herbig@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:12 c.herbig@…]:

A downside with using notes is that they don't show up in port info NAME, so if the user misses the notes section after it is installed, they might not know how to get back to see what it was. This can happen when they are installing a chain of ports and the notes gets buried behind a lot of other messages, like the way that the notes for dbus do.

Admittedly true. There’s been [[ticket:24507|a ticket]] on this, as well as at least one [http://thread.gmane.org/gmane.os.apple.macports.user/31300/ absurdly convoluted mailing list discussion]. -- Ticket URL: <https://trac.macports.org/ticket/39897#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X