Le ven. 3 sept. 2021 à 00:39, Phil Morrell <deb...@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
