Give clear semantic meaning for each directive

to follow up on this thought, here is what I came up with from a quick thought experiment

• dependencies: modules listed must be enabled for this module to be enabled.
• recommends: whenever this module is enabled these modules are offered as subsequent options (not a big fan of this one but can see why some might want it).
• conflicts: any modules listed here may not be enabled when this module is enabled.
• replaces: this would address the "module renaming" use case that is currently severely broken in Drupal. That is, currently there is no way to rename your module safely. Period. When Drupal re-scans for modules, finds that one that used to exist no longer does, it flips the status bit in the system table and your newly named module is screwed for figuring out whether the previously named module was turned on or off. Ideally replaces would let Drupal not flip this bit but smoothly transition schema versions etc. to the new name.

I cannot come up with ideas for suggests, enhances and breaks that are not redundant with those above.

This comment explains the meaning for each word well: http://drupal.org/node/328932#comment-2031276

Depends -> MUST be enabled
Pre-depends -> MUST already be enabled
Recommends -> SHOULD be enabled
Suggests -> MAY be enabled
Enhances -> MAY be enabled
Conflicts -> MUST NOT be enabled

Personally, I think that all dependencies should be installed and enabled before trying to install any module (my goodness that would make my life so much easier...).

I do agree that recommends, suggests and enhances may just be too much information. Especially since in the above semantic definitions of each, both 'suggests' and 'enhances' have the same meaning.

So, I dove into this issue because I actually want to auto install several modules if they are around. They aren't strictly dependencies, but if they exist I'd like them automatically enabled. I think I'll set it up so that any module that lists "recommends[]" in their .info will have those modules install if they exist.

I know nothing about this module, but followed the core brainstorm a while back #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files
'Suggests' and 'Enhances' are two ends of the same relationship.

In D6,
Imagecache 'Enhances' Imagefield.
Imagefield 'Suggests' Imagecache.

If that's the case, then 'Suggests' sounds like a rephrasing of "is enhanced by".

However the difference between 'suggests' and 'recommends' comes down only to what someone was feeling at the time.
Any module that implements another modules hook or modifies another modules form probably "enhances" or "extends" it, so that's a measurable state. What the enhanced module feels about that is just down to personality. :-B

I feel it is absolutely normal that...
maintainers (say cck/content) recommend and suggest modules...

But many many more other modules enhance those modules (cck) and provide proper extended functionality.
There's no need bo be approved (recommended/suggested by origin maintainer) but you're able to implement hooks (enhance).

It would be very clear to define "enhances" as "we implement hooks of", but we might see situations which don't apply perfectly.

Especially in an open community we will result in different states between recommendation/suggestion and enhances.

subscribing

Subscribe.

I agree very much with this issue and I really think we should standardize the semantics upon accepted meanings from existing systems as I wrote in the main issue and which #2 referred to.

The wheel has not to be reenvented:

pear has a nice package format and description ,

I'd suggest also to check Debian Packageing.

I.m.h.O. Drupal lacks a package-management-tool …

@Thomas: I totally agree. The list in #2 is actually adopted from Debian - I think that's why it includes the somewhat odd "pre-depends". It's taken from http://www.debian.org/doc/debian-policy/ch-relationships.html which was linked to here: http://drupal.org/node/328932#comment-1120761