21. Formalize optional_features

Proposal:

Optional features: is supported in META.yml, but it requires a lot of
manual intervention and trickery to make it work. And it is very poorly
documented. (Tux)

Comments:

* Not all YAML parsers parse that structure the same way, so the order of
  this section inside META.yml is vital (still :()

* I for one would be happy to see optional_features: removed entirely,
  since actual actions resulting from this information only apply in the
  human-in-the-loop cases. It also locks downstream packagers into either
  supporting it or not supporting it, none of THEIR users actually get a
  choice (AdamKennedy).

* optional_features may be used automatically. This is already implemented
  in CPAN.pm in conjunction with the "features" key of distroprefs.
  (SlavenRezic)

* optional_features can be however quite practical to people with source
  based distributions as long as they're done properly. Gentoo tends to
  match each optional_feature to a corresponding 'use' flag. ( Set it and
  forget it ). (kentnl)

* The example of optional_features express a optional 'feature' as having
  'requires' prerequisites as an 'alternative' to specifying 'recommends'.
  But what would 'build_requires' within an 'optional_features' entry mean?
  Is 'recommends' allowed within 'optional_features'?  What should
  CPAN(PLUS) do for each of the prerequisite types if found under an
  optional_feature entry? (Dagolden)

Reply via email to