• Re: Embedded code copies for gamescope

    From The Wanderer@21:1/5 to Ilya Orlov on Sun Jul 13 15:40:01 2025
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
    On 2025-07-13 at 09:03, Ilya Orlov wrote:

    Hi everyone!

    Upstream gamescope[1] have several embedded copies which current
    packaging changes for system libraries (except reshade patch[2]).
    But after looking at upstream git commits I believe upstream fully
    intends to use these dependencies in an embedded way.

    <snip reasonable- and persuasive-seeming details>

    Debian policy[9] states:

    Debian packages should not make use of these convenience copies
    unless the included package is explicitly intended to be used in
    this way.

    I believe that upstream makes it very clear that it's their
    intention.

    The way I parse that statement in Policy is that the convenience copies
    should not be used unless *the code being included* is explicitly
    intended *by **its** upstream* to be used via embedding it. The
    intentions of the upstream who are *doing* the embedding would not seem relevant.

    There might still be reason to accept doing it in this case - that's
    outside of my scope to be able to assess - but I would be surprised to
    learn that it was within the intention of this part of Policy.

    --
    The Wanderer

    The reasonable man adapts himself to the world; the unreasonable one
    persists in trying to adapt the world to himself. Therefore all
    progress depends on the unreasonable man. -- George Bernard Shaw


    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmhztH8ACgkQBKk1jTQo Mmt/HRAAm/WRbqkAxT4JOEGoRNvWKYdGpGHiNT0SVCU3FteqyuJdQdPU0lCszU8h bKguC5fgKG1Rx8mJyHt14q6JO/5QuC+78mogjAQtyGk85XFMj8o8uC9fNm8tswmw 1bMfZg3iarY2KtxmHe3AwuLsga+GdTFEZ/hVtabdE9YeZQMmwTrbuxVxEK9vw0r2 fC6Pk0ReK2pndlCNMzbjEJThTblrjdU7/E9agegCYavJAmu8KGhidG3hdDbcci0c RpV+nM5NV3W/OhE4Qs6aVIN/BkZGKPYSsgCAQ0PCxin+BrGvZWdWYaw5oBYYhff7 y5Uz2RemYTdyUNc/v1rjvmVwOGMxQ3mpwEYoG2c0u+CN/3NvLNSxv/IbaeL2GBkU //fD5FYlZK+306viAu91SVWxaKhy894IfLoQZjik4TfTozuzj9T65Xv+l0kwhOza v9lkA+pPHhINt+vUndfkoMjkK/WYlN0fvEHei8xumgt8PCshuqcq57nGsbqxk55J +5IOveU/zVxvfpD3lLBM6hl2eTDSUIM/mBNuWqvWUaiQPsJSjncefs14+twclIOd 3JJwX071CccBCe6Hrd8sxyWP1+LjcvbLPVdoaPoYxUydH8jTEXaF06nwmo3mj6WX RY1ktnAxNfXLLcDZsYk69askOJ3Q
  • From Daniel =?utf-8?Q?Gr=C3=B6ber?=@21:1/5 to Ilya Orlov on Sun Jul 13 16:00:01 2025
    On Sun, Jul 13, 2025 at 06:03:56PM +0500, Ilya Orlov wrote:
    And if you think it's a good idea I would appreciate some directions
    on what is the best way to embed git submodules and meson subprojects
    in the source package.

    As of devscripts 2.25.11 uscan has support for git submodules - Thanks hmc!

    https://salsa.debian.org/debian/devscripts/-/merge_requests/480

    This will give you a single orig tarball made up of a concatenation of git-archive(1) exports of the individual git trees.

    Here's an example from one of my packages where I needed this:

    https://salsa.debian.org/electronics-team/nextpnr/-/blob/master/debian/watch

    Pretty simple.

    --Daniel

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAmhzur8ACgkQ05SBrh55 rPeq2w//VD1aQeI9cCf50l0wrtWDGDlh0agAhmvVC0MANRrUh5iOLK5KP6kJy78f 6kjrvHV9pd6MIiaoVwVG8Cj7whchGMn333s7T0iNlB7MMiCWkBhiam7GK9jU6ICw StuTD01yEIL+uSZz+aaEg7Yle0m/MI4IBlaNnm29bOiSc9uGX8sc5wXMyJR0vRpG 174D3jFjRGPliW22bMcsykcPuDxbByAG+2D9KObRdO4ZR87Pevicdsr7u5Xm1Cz4 sQ1TJWoTOef4iMHmMAftyyhl35aJEHXK3ptK4ao/GiQ1Y5tvAjuFd2QZq7gqb6Gr eDV6Kx0LrvrJn6u4ofm3nbZpkZyDMcrjmVyip2Uusam82j9SEbcLRR34/VdywFnj MgsKNxuEcH8eg9k0x93VGDKxizL9dfI0tOeshx6H/VFk5dh6ErDLCi07Kf5Zb/dw qN/ecS07pEm5v1O6G5T5c/Wrhae162XHkKS5ggwjwOTldwYXK65faKpc2d8YA+bq I1++WwNk9+A857WIbmkfnuw32WONx6UGM/hMbxCmCbYvpcKR00qfufDaQzyNYzMT fBfWCD0obVdXfYtmecMOEI/insBg+GkTOKjLouFordPuSGiTIWNqG4qPZUoUjgK9 jOa0RjQLsOGF4y8IYAEoY7xP2Vo2T96qEBm9IPG2UaYMDr9VYXA=
    =NpA4
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Colin Watson@21:1/5 to The Wanderer on Sun Jul 13 16:50:01 2025
    On Sun, Jul 13, 2025 at 09:28:31AM -0400, The Wanderer wrote:
    On 2025-07-13 at 09:03, Ilya Orlov wrote:
    Debian policy[9] states:

    Debian packages should not make use of these convenience copies
    unless the included package is explicitly intended to be used in
    this way.

    I believe that upstream makes it very clear that it's their
    intention.

    The way I parse that statement in Policy is that the convenience copies >should not be used unless *the code being included* is explicitly
    intended *by **its** upstream* to be used via embedding it. The
    intentions of the upstream who are *doing* the embedding would not seem >relevant.

    Yes, I was involved in drafting that policy language and the way you
    describe it is what we intended. Otherwise the whole clause would have
    been a no-op in practice.

    --
    Colin Watson (he/him) [cjwatson@debian.org]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Colin Watson@21:1/5 to Ilya Orlov on Mon Jul 14 08:40:02 2025
    On Mon, Jul 14, 2025 at 10:46:35AM +0500, Ilya Orlov wrote:
    Ah, I see. So with this policy it would be ok to embed:
    wlroots and reshade - because it's forks made specifically to be used
    in gamescope submodules.

    No, only if the original wlroots and reshade projects were ones that
    were intended to be used via vendoring/embedding.

    Again, if the policy clause were simply about the intent of a fork of
    some original library, it would be almost completely ineffective,
    because when people fork libraries and copy them into their projects
    they generally intend to do so; that doesn't mean that Debian wants to
    support that.

    The point of that policy exception was to avoid outlawing things like
    Gnulib (https://www.gnu.org/software/gnulib/), which is specifically
    designed from the start to be copied into projects at the source level
    (and comes with various tools to make that more maintainable). It's a
    very different kind of thing.

    Even then, more recently there's been a movement to regenerate Gnulib
    files in packages that use it from the gnulib package in Debian.

    vkroots - because the creator of a project intends it to be used via >embedding (but it's already packaged with specific commit needed by >gamescope, so it's fine for now)

    I'm not quite sure from looking at https://github.com/misyltoad/vkroots,
    but that may be OK. If it's easy to use the packaged version, that's
    better.

    --
    Colin Watson (he/him) [cjwatson@debian.org]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)