Packaging info from .info.yml often creates conflicts when patching (ddo)

This is the right place for packaging, more newlines could be added at https://git.drupalcode.org/project/drupalorg/blob/dev/drupalorg_project/...

I don’t think any other change is possible without Drupal core knowing to look in another place, and a project requiring at least that version of core. Taking away data update status and other modules depend on isn’t something we can do right away.

I think the best path forward here is for core to expect data in either the .info.yml files, or in a new .drupalorg.packaging file that can be gitignored, but would have added data in it.

manipulating the metadata files is a throwback to earlier cvs days, and I think we've got better ways to handle this now.

Will still be a problem with the .info.yml files of sub-modules being deleted.

Packaging shouldn’t be deleting any .info.yml files. Do you have an example of this happening?

I think that meant "If the patch deletes a submodule's .info.yml" for whatever reason, it will fail.

I think this is a real blocker for many composer-based sites moving over to or starting builds out on Drupal 9, because many modules in the community are not yet fully D9 ready. Thanks to tools like Drupal-check, there are many patches getting added and committed to projects to fix the deprecated code issues, but the other part of making a module D9 ready is it having the `core_version_requirement` line in the info.yml file.

Some modules have been providing this already and typically is included in the next major version, or at least in the latest Dev version. When the `core_version_requirement` line is already committed to a stable or dev release, it works fine.

But many modules still are missing this single, one-line change, and could be likely due to the same issue I've come across when attempting to create patches to add `core_version_requirement` to the info.yml file. The issue is that when applying the patch to a Git clone of the project, it works great. But, when the patch is included in composer.json "extra/patches" section, due to things noted in this issue and how package information is added, the patch fails to apply.

In some cases, we have been successful getting a patch to apply, but it feels super hacky with how it had to work because the `core_version_requirement` line was in an odd location in the info.yml, such as above the `description` line. This is due to the rule that there needs to be 3 lines above the diff and 3 lines below the diff, so that the package information can be placed in the info.yml given those lines and locations.

FYI this is a good example to add context to my previous #7 comment:
https://www.drupal.org/project/videojs/issues/3175575#comment-13852809

You can see there is a patch in that issue to add the `core_version_requirement` line.
But, when i apply that patch via composer patches ("extra/patches") via the composer-patches plugin with Composer:
https://github.com/cweagans/composer-patches

It does not apply cleanly. Here is the .rej file output:

***************
*** 2,5 ****
  type: module
  description: Video.js is an HTML5 Video Player.
  package: Media
- core: 8.x--- 2,5 ----
  type: module
  description: Video.js is an HTML5 Video Player.
  package: Media
+ core_version_requirement: ^8.8 || ^9

Ran into this in Commerce Migrate, #3179943: Can't install on a clean version of 9.0.7 with composer

Ran into this in LayoutBuilder Search API install on Drupal 10. https://www.drupal.org/project/layoutbuilder_search_api/issues/3371584

I have run into this in multiple occassions, today being the latest incident. I remember having the very same issue a few years ago and drumm fixing it. I think it was drumm.