[libdrm] New port

[dg0yt]

To be used (at least) by mesa.

[Neumann-A]

deja vu, was also part of #26858. Requires libpciaccess.
Question was: Should this be provided by the system (were exactly does vcpkg want to put the boundary)?

[dg0yt]

Requires libpciaccess.

Or simply auto-disables libdrm_intel.

Question was: Should this be provided by the system (were exactly does vcpkg want to put the boundary)?

👍
With the added difficulty of desktop systems generally using shared libs, vcpkg CI building static libs.

[dg0yt]

This PR is also integrated in #36081 to provide a more recent libdrm to mesa.

[Neumann-A]

With the added difficulty of desktop systems generally using shared libs, vcpkg CI building static libs.

#27279 removed all system libs so it is theoretically possible. The question is: Is it practical?
If vcpkg wants to make those libs shared it could simply use per port customization in the triplet.
I am a bit torn if those libs should be system provided or not. It seems like all those libs are user space any way and could be provided by vcpkg.

[dg0yt]

The task is to have reasonable CI coverage for ports like mesa.
I wouldn't mind having a few more system dependencies made explicit via empty ports, and to add overlay ports to fill gaps in CI.

Things get tricky when system packages pull in runtime libs which are also libs in vcpkg. libdrm is a candidate...

[dg0yt]

Using libs provided by the operating system might also mitigate some licensing concerns.

[BillyONeal]

Tagging vcpkg-team-review: I'm really nervous about checking in a copy of the license which is not anchored in any way to where the code comes from, thus making bugs where we claim the license is one thing and it's actually something else in the future.

[dg0yt]

I'd be really nervous about the superficial copyright files for most ports. While vcpkg started with ideas from Debian packaging (CONTROL, copyright), it didn't really adopt the thorough copyright part, and the gap is significant and obvious.