Re: Package dependency versions and consistency
On Mon, Dec 28, 2020 at 03:51:12PM -0800, Josh Triplett wrote:
> On Mon, Dec 28, 2020 at 03:20:35PM +0200, Adrian Bunk wrote:
> > On Sat, Dec 26, 2020 at 02:55:17PM -0800, Josh Triplett wrote:
>...
> 2) There's not enough benefit to the patch to carry it downstream. This
> is part of the point of this thread: allow transitions to happen in
> the archive and in concert with upstream, rather than before first
> upload or via Debian-specific changes.
>...
> If you need a targeted bugfix in
> the old version, it's possible to publish a new micro-version of the
> package containing just that bugfix.
>...
Don't assume upstream.
The vast majority of packages in a distribution has/had one person as
upstream. This is a single point of failure, and it fails frequently.
There is software in Debian whose upstream died in the last millenium,
more common is that upstream just found another hobby or got a new job
or children.
Sometimes upstream becomes active again after a decade or two when the
children are older or pension age is reached.
In more scientific areas of the archive it is common that software was
written for a Bachelor/Masters/PhD thesis or a funded science project
and abandoned by the author afterwards.
Just a few days ago I pinged upstream regarding a bug in a game in Debian.
The game was written in the 1982 and the version in Debian is from 1992.
Luckily upstream is still alive and is even an active Debian developer
today so that was easy to resolve, but the far more common case would
have been to resolve the problem in a Debian-specific change.
>...
> > The way a distribution like Debian works, I do not see how security
> > support would be possible for a static-only ecosystem with a non-trivial
> > number of packages.
>
> Cheaper binNMU-style rebuilds, and better incremental downloads. This is
> a solvable problem, once you start from the perspective that it requires
> a solution.
There is a huge amount of arrogance in the Rust community when it comes
to taking any responsibility for maintainability or security.
This includes the Debian Rust Maintainers, who do not feel responsible
to maintain whatever they dumped into Debian stable releases.
The root problem is that we are letting people get away with such
antisocial behaviour, and suggestions for solutions would be less
lunatic if the people who want the Rust ecosystem in Debian would first
have to implement themselves whatever is needed to provide security
support.
I do not have the time and energy to attempt getting the whole Rust
ecosystem removed from bullseye, but short-term this would be the
only option to protect our users from the insecure Rust ecosystem.
If anyone would care about security of software written in Rust shipped
in distributions and wanted to implement a solution, my first question
would be:
With semver the API is already guaranteed to be 100% backwards
compatible with all previous releases implementing the same semver.
Why don't you use this guarantee to build a libxyz.so.2 for semver xyz-2?
> - Josh Triplett
cu
Adrian
Reply to: