Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #101501

Re: Finding rough consensus on level of vendoring for large upstreams

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Le ven. 3 sept. 2021 à 00:39, Phil Morrell <debian@emorrp1.name> a écrit :

> Over this last year there seems to have been a noticeable divergence of
> maintainer opinion, on what has become known as vendoring, from a strict
> reading of [policy 4.13]. I think it's notable that the heading is
> [Embedded] copies and was [Convenience] copies since its inception,
> thankfully I found a request to expand this section using [vendoring].
>
> [policy 4.13]:
> https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
> [Embedded]: https://bugs.debian.org/955036
> [Convenience]: https://bugs.debian.org/392362
> [vendoring]: https://bugs.debian.org/907051
>
> It is my reading of the situation that not only has this practice become
> more prevalent across multiple ecosystems since 2008, but that it can be
> a good thing when upstreams use it to better modularise their code. As a
> consequence, and in particular for large upstream projects, it is not a
> good use of maintainer time to package every single vendored library as
> a separate source package. See e.g. [kubernetes], [python BoF @25mins],
> [android-platform-tools], and even [uscan] grouping used by nodejs.
>
> [kubernetes]: https://bugs.debian.org/971515#172
> [python BoF @25mins]:
> https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm
> [android-platform-tools
> <https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm%5Bandroid-platform-tools>]:
> https://salsa.debian.org/android-tools-team/admin/-/issues/40
> [uscan]: https://manpages.debian.org/uscan#grouped_package
>
> Is there any objection to the following summary?
>

> 1. If the reused code is small and intended to be embedded into a
>    package, then this MUST be documented in the [security-tracker].
> 2. If the included project has already been packaged, then the Debian
>    version SHOULD be used instead.
> 3. If modifications have been made, then those changes SHOULD be
>    forwarded and/or the package ported to the official version.
> 4. When 2 or 3 are too onerous to maintain, the package MAY use the
>    convenience copy but MUST document why in README.source and SHOULD be
>    included in the [security-tracker].
> 5. Where only a small number of unrelated projects are bundled, they
>    SHOULD be uploaded as separate source packages.
> 6. If the upstream authors are largely the same, then vendored
>    sub-projects MAY simply be built together as the same source.
> 7. A large number of vendored dependencies used only together for a
>    single Debian package MAY be grouped into a single source upload.
> 8. If 6 or 7 are used initially but a new package has some overlap, then
>    the new package MUST NOT duplicate the vendoring. The duplication
>    SHOULD be packaged separately, then the original package SHOULD be
>    updated to use the Debian version instead.
> 9. When upstream has a proven track record of promptly handling security
>    vulnerabilities inside their vendored dependencies, then maintainers
>    SHOULD follow the same practice, updating versions in lockstep.
>

a couple naive questions:
- should a package debian/control list bundled dependencies to make
sure to avoid duplications ?
- when a bundled package dependency is already available in debian,
and is the same (unpatched), should the upstream source tarball be
repacked without that dependency, or kept inside the source tarball ?

Jérémy

Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Finding rough consensus on level of vendoring for large upstreams Phil Morrell <debian@emorrp1.name> - 2021-09-03 00:40 +0200
  Re: Finding rough consensus on level of vendoring for large upstreams Jérémy Lal <kapouer@melix.org> - 2021-09-03 01:20 +0200
    Re: Finding rough consensus on level of vendoring for large upstreams Phil Morrell <debian@emorrp1.name> - 2021-09-03 03:10 +0200
      Re: Finding rough consensus on level of vendoring for large upstreams Gunnar Wolf <gwolf@debian.org> - 2021-09-03 17:30 +0200
  Re: Finding rough consensus on level of vendoring for large upstreams Jonas Smedegaard <jonas@jones.dk> - 2021-09-03 02:50 +0200
    Re: Finding rough consensus on level of vendoring for large upstreams Phil Morrell <debian@emorrp1.name> - 2021-09-03 03:40 +0200
      Re: Finding rough consensus on level of vendoring for large upstreams Jonas Smedegaard <jonas@jones.dk> - 2021-09-03 05:00 +0200
        Re: Finding rough consensus on level of vendoring for large upstreams Pirate Praveen <praveen@onenetbeyond.org> - 2021-09-03 18:50 +0200
    Bug#907051: Finding rough consensus on level of vendoring for large upstreams Simon McVittie <smcv@debian.org> - 2021-09-03 11:30 +0200
  Re: Finding rough consensus on level of vendoring for large upstreams Paul Wise <pabs@debian.org> - 2021-09-03 05:30 +0200
  Re: Finding rough consensus on level of vendoring for large upstreams "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-09-03 10:20 +0200
  Re: Finding rough consensus on level of vendoring for large upstreams Adrian Bunk <bunk@debian.org> - 2021-09-12 19:20 +0200
    Re: Finding rough consensus on level of vendoring for large upstreams Phil Morrell <debian@emorrp1.name> - 2021-09-15 17:40 +0200

csiph-web