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


Groups > linux.debian.devel > #101525

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

From Gunnar Wolf <gwolf@debian.org>
Newsgroups linux.debian.devel
Subject Re: Finding rough consensus on level of vendoring for large upstreams
Date 2021-09-03 17:30 +0200
Message-ID <CTjiF-77Q-3@gated-at.bofh.it> (permalink)
References <CT3xg-4QP-9@gated-at.bofh.it> <CT40h-5gQ-1@gated-at.bofh.it> <CT5Sp-6s4-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Phil Morrell dijo [Fri, Sep 03, 2021 at 02:04:44AM +0100]:
> On Fri, Sep 03, 2021 at 01:03:35AM +0200, Jérémy Lal wrote:
> > - should a package debian/control list bundled dependencies to make
> > sure to avoid duplications ?
> 
> Maybe? I noted in my final paragraph that Fedora has a mechanism for
> this that we don't, but perhaps Provides is sufficient.

Although it very seldom the case IMO.

Even if we don't take into account the horrible practice of vendoring
*and then patching* libraries done by some upstreams, we do ship (and
our shipped packages depend on) specific versions of libraries. One of
the ugly things about vendoring is that they bundle _other_ specific
versions of libraries -- and dependencies are often quite hard to
update without wrecking havoc in its whole ecosystem :-(

> I omitted this from the policy side, because it seems like this is
> already answered in ftp-master practice. Provided the vendored copy is
> not used during the build and unless there is a *different* reason for
> repacking with Files-Excluded, then I see no reason to remove it.

Completely agree. Many packages vendor i.e. rendering libraries to
produce their documentation at build time, and such libraries are not
needed for the package once built.

My example might not be great, because we still like building the
documentation (and thus they would not qualify for Files-Excluded,
only for omitting them from the binary package), but you get the idea
:)

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