feat(AppStream): Added metadata XML listing supported hardware (ESPTOOL-983)

[petterreinholdtsen]

This allow programs like isenkram to map relevant hardware to this package, and propose to install the package when supported hardware is available.

This patch was originally submitted to Debian as https://bugs.debian.org/1079458 .

The change is not tested, I do not own any relevant hardware myself. (NO TESTING)

[github-actions]

Warnings

⚠️

Some issues found for the commit messages in this PR: the commit message "feat(AppStream): Added metadata XML listing supported hardware": scope/component should be lowercase without whitespace, allowed special characters are _ / . , * - . Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).

👋 Hello petterreinholdtsen, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against 065c207

[radimkarnis]

Hi @petterreinholdtsen,

Thanks for the contribution! We appreciate the effort you’ve put into this.

Unfortunately, there are several reasons why we don’t plan to support this:

1. Maintaining the VID:PID list
   Tracking and maintaining an accurate list of VID:PID pairs for USB devices is outside the scope of this repository. The provided list appears to cover various USB-UART bridges from multiple manufacturers, and it’s nearly impossible for us to verify its completeness or accuracy.
   Adding and maintaining this metadata introduces a maintenance responsibility. Given the fast-evolving nature of embedded, keeping the metadata up-to-date would require ongoing effort.

2. General-purpose nature of USB-UART bridges
   USB-UART bridges (e.g., CP2102, FT232, CH340) are generic devices that can be used with a wide range of hardware, not just Espressif chips. Adding esptool as a recommended package for such devices would likely lead to false positives, causing confusion for users working with non-Espressif hardware.

3. Focus on core functionality
   Esptool’s primary purpose is to interact with Espressif chips' bootloader. Expanding the project to include metadata for hardware of other manufacturers creates unnecessary complexity.

4. Esptool is not primarily used standalone
   Installing esptool might not be the most useful recommendation for new users. Esptool is usually utilized under the hood of development frameworks (like PlatformIO or Arduino IDE), and its interface is hidden from the user. Typically, only more advanced users download and use esptool standalone—and these users already know what they are looking for, so they wouldn’t benefit much from an autodiscovery feature.

We hope you understand our decision not to include this patch. Thanks again for your contribution.

Radim

[petterreinholdtsen]

[Radim Karniš]

Unfortunately, there are several reasons why we don’t plan to support this:

Sad to hear this. Note, I believe my proposed list of modalias entries listed is based on the entires in the udev rules defined on Debian, where the driver cdc_acm list these entries according to '/sbin/modinfo cdc_acm'. It provide a simple and automatic way to update the list. In any case, thank you for letting me know about your rationale. I guess the esptool package will not join the currently 113 and growing packages in Debian prividing hardware mappings with AppStream making it possible to automatically propose the package when relevant hardware is present. Who knows, it might change some day in the future. :)

…

-- Happy hacking Petter Reinholdtsen

[dobairoland]

Note, I believe my proposed list of modalias entries listed is based on
the entires in the udev rules defined on Debian, where the driver
cdc_acm list these entries according to '/sbin/modinfo cdc_acm'. It
provide a simple and automatic way to update the list.

This sounds pretty much to me something which could be better generated/maintained on the Debian side. And the resulting file applied as a post-installation patch.

Just for future readers I'd like to point out that esptool has a filtering capability (https://docs.espressif.com/projects/esptool/en/latest/esp32/esptool/advanced-options.html#filtering-serial-ports) which can be used to achieve something similar. VID:PID-based filters can be defined which will narrow down ports during finding the right serial ports among the available ones. I know it is not the same as the purpose of the PR.