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


Groups > linux.debian.maint.python > #13950

Re: Advice wanted: handling weird vendoring situation

From Julian Gilbey <julian@d-and-j.net>
Newsgroups linux.debian.maint.python
Subject Re: Advice wanted: handling weird vendoring situation
Date 2022-02-16 17:30 +0100
Message-ID <DRvlL-2eA3-1@gated-at.bofh.it> (permalink)
References <DOjK9-fzz-1@gated-at.bofh.it> <DOsNr-lBo-5@gated-at.bofh.it> <DP02J-FXm-1@gated-at.bofh.it> <DQ87T-1nFR-3@gated-at.bofh.it> <DQkVs-1vNG-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sun, Feb 13, 2022 at 12:07:44PM +0100, Gregor Riepl wrote:
> > So the solution I'm currently in the process of trying is to copy the
> > version from the oldest supported Python version at Debian package
> > build time.  We'll see how this goes....
> > 
> >> Perhaps they have a maintenance script for updating the vendored
> >> dependencies? You could use that to find out how to reverse the changes,
> >> or start from a clean slate?
> > 
> > Unlikely; some of their vendored dependencies date back to Python 2.5!
> 
> In that case, I think this is the issue that must be solved first:
> Ensuring that their code is compatible with the *latest* published
> version, and vendoring the system version at build time.

Hi Gregor,

Thanks for your thoughts.

Yes, and that is what I'm going with.  Unfortunately, upstream are
trying to keep pydevd compatible with almost every version of Python
that exists (Python 2.7, Python 3.x, PyPy, IronPython and Jython), so
they cannot necessarily use the latest versions of the library.  But
I'm only going to aim to support the supported versions of CPython in
Debian, so I can use the latest versions of the library.  (Actually, I
am using the version in the lowest Debian-supported version of Python,
in case a newer version of the library uses newly introduced syntax.)

> Not a good solution, since it will still leave the system vulnerable
> when one of the dependencies gets a security update, but better than
> shipping a static version that might have numerous issues and will no
> longer receive any patches.

Indeed.

> The alternative would be that they take full responsibility for their
> vendored code, but then it will be much harder to detect when they're
> affected by a vulnerability.

Quite.

Best wishes,

   Julian

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


Thread

Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-07 22:30 +0100
  Re: Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-08 08:10 +0100
    Re: Advice wanted: handling weird vendoring situation Gregor Riepl <onitake@gmail.com> - 2022-02-09 19:40 +0100
      Re: Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-12 22:30 +0100
        Re: Advice wanted: handling weird vendoring situation Gregor Riepl <onitake@gmail.com> - 2022-02-13 12:10 +0100
          Re: Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-16 17:30 +0100

csiph-web