Dmitry E. Oboukhov dijo [Tue, Feb 03, 2026 at 05:52:59PM +0300]:
A bit of statistics for consideration.

In Debian/trixie there are currently 68,756 packages (I just
downloaded and counted). Of those, 11,877 are libraries that have
exactly one reverse dependency. That is 17% of the effort that
could have been spent on something else. And users would notice
no difference if all those packages were bundled into the one
package they exist for.

It might be so in the present. But if you build a _second_ package using
the same library, it will instantaneously become a time saver. Yes, I
recognize it amounts to wishful thinking — but I do also see it as keeping
a valuable engineering principle, and even patching upstream code to relax
specific dependencies helps show upstreams the "lazy way" is not the only
way.

I am not saying "we should do it this way". I am saying it would
be good to explicitly allow that "it can be done this way", and
sometimes (when upstream is opposed to separate packaging) it may
even be the right thing to do.

As you can guess by now, I am not a fan of vendoring. It has bitten me, and
it has reduced the amount of software I maintain in Debian. Particularly, I
used to be the maintainer of the drupal7 package, but drupal >= 8
transitioned to a ugly vendoring scheme that I found impossible to keep up
with... And yes, our users lost the packaging for this truly great
software, because its engineering practices got sloppier.

Now, if your proposal is accepted... should we gain back packages such as
Drupal? No, I don't think so. I don't think it can be reasonably packaged
by us giving the quality assurance we are proud in giving. It can, of
course, be converted into an easy-to-install .deb package, but losing all
of the systemwide integration that, in my eyes, is a fundamental part of
what Debian promises, and usually delivers. Not only that: what about
security support for ~2 years for our stable releases? Would I be able to
backport fixes into older releases? Clearly not.

Reply via email to