[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.

[BillyONeal]

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.

Debian's case and ours are very different. Debian is doing distribution and thus have license requirements to comply with themselves, so they actually are implicated in needing to do license audits. We very explicitly do not rehost or distribute the licensed content ourselves; this is one of the big reasons we have been sparing in trying to rehost things; each individual thing requires lawyers to look.

For example, the xbox folks wanted a litmus test for 'can't deploy GPL here'. It's more for a dev asking 'can I use this thing at all?' -- we expect that customers are going to need to do their own legal reviews or similar. We are not going to defend customers based on such claims, any more than GitHub is going to defend you when they tag a repo based on a COPYING file in the repo.