4 ms·

The point echoed in this discussion multiple times is that distributions should not handle the tiny python libraries and attempt to solve the dependency version

The point echoed in this discussion multiple times is that distributions should not handle the tiny python libraries and attempt to solve the dependency version issues, but treat an application with all its dependencies included as a single package. If a dependency needs to be bumped a version for e.g. security purposes, then the app obviously wasn't tested with the new version (which didn't exist at the time) and needs to be retested, repackaged and rereleased for the update. This would cut down on the number of packages to be maintained, as the vast majority of python libraries would be exclude from the direct packaging process.

goodpoint 5y ago
> If a dependency needs to be bumped a version for e.g. security purposes, then the app obviously wasn't tested with the new version (which didn't exist at the time) and needs to be retested The burden of updating multiple copies of the same library across many packages grows exponentially and is simply untenable for distributions. If you can find an army of volunteers to do that, distributions would love their contributions. This hasn't happened in the last 20 years. I'd love to be proven wrong.
- PeterisP 5y ago
  Since simply updating the dependency can easily break the resulting package, this need to re-test is not something that can be avoided by making some other choice of packaging e.g. the current one - it's not adding a new burden, it's acknowledging that it already exists (indeed, IMHO much of what the original article complains about). If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives.
  - goodpoint 5y ago
    I wrote "The burden of updating". Testing still needs to be done but there's a lot of automation to minimize the workload. > If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives. No, most upstreams do not backport security fixes. And switching to a newer release is not an option if you want to provide stability to users.

goodpoint 5y ago

> If a dependency needs to be bumped a version for e.g. security purposes, then the app obviously wasn't tested with the new version (which didn't exist at the time) and needs to be retested The burden of updating multiple copies of the same library across many packages grows exponentially and is simply untenable for distributions. If you can find an army of volunteers to do that, distributions would love their contributions. This hasn't happened in the last 20 years. I'd love to be proven wrong.

PeterisP 5y ago
Since simply updating the dependency can easily break the resulting package, this need to re-test is not something that can be avoided by making some other choice of packaging e.g. the current one - it's not adding a new burden, it's acknowledging that it already exists (indeed, IMHO much of what the original article complains about). If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives.
- goodpoint 5y ago
  I wrote "The burden of updating". Testing still needs to be done but there's a lot of automation to minimize the workload. > If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives. No, most upstreams do not backport security fixes. And switching to a newer release is not an option if you want to provide stability to users.