Re: Advice wanted: handling weird vendoring situation

[Julian Gilbey <julian@d-and-j.net>]

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