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

Groups > linux.debian.devel > #101500

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

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://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.

I might be misusing the MUST/SHOULD/MAY, so those can be dropped as
needed, but I tried to capture the accepted practice and deliberately
used all the different historical terms. For comparison, there's also
[Fedora] policy, but apart from not having an in-band "bundled", I also
think that the line has ended up being drawn marginally differently.

[security-tracker]: https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies
[Fedora] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling

Back to linux.debian.devel | Previous | Next — 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