Re: What to do when DD considers policy to be optional? [kubernetes]
On Sat, 28 Mar 2020 12:41:46 +1100, Dmitry Smirnov
<onlyjob@debian.org> wrote:
>On Friday, 27 March 2020 7:08:35 PM AEDT Marc Haber wrote:
>> Many upstreams deliver .deb packages of their current releases in
>> noticeably high quality from a Debian point of view. One should look
>> at them before putting them in production.
>
>I have a very different observations regarding upstream packaging for Debian.
>Most vendor packages are of notoriously bad quality, disconnected from Debian
>practices and bug reports, not benefiting from QA and continuous testing,
>heavily compromising on policy compliance, not following library transitions,
>etc., etc.
You're right, that makes them unsuitable for a Debian release.
And yes, I have also seen "upstream" packages that were obviousy
aliened rpm packages with zero adaption to the .deb world, including
vendor instructions to dpkg --install them with --force-everything,
very obviously breaking our dependency mechanisms.
And I have also seen "upstream" packages that went ahead in their
postinst to replace /lib/<something>/libc.so.6 with their own, older
version.
But I have also seen the Ubuquiti .debs, the Upstream docker .debs and
the Upstream icinga .debs, which find a rather enticing middle way
between being of high quality _and_ offering current Software for
Debian stable. I do not have big doubts that the Upstream k8s packages
will also fall in this category (not having looked at them).
>The very existence of vendor packaging often indicates unwillingness to do
>the job properly, up to our standards, and maybe even unwillingness to
>cooperate with Debian to achieve proper integration. Precisely because it is
>easier to do a quick sloppy work that won't be accepted without much
>improvements.
Why would someone jump through our burning loops if the package is not
going to be in stable anyway, or horribly outdated when it has finally
reached stable. There are projects that don't want to support their
software in a version that has been released two years ago. That's a
valid approach, and one that I can fully understand from a software
project's point of view.
>>From vendor prospective having their own packages asserts exclusive control -
>a something that some appreciate more than proper integration with Debian or
>benefits of distributing software with/through Debian.
You can offer proper (or just "good enough") integration into Debian
yourself, and having an obsolete version of the software distributed
with/through Debian is (rightfully) seen a liabilty by some upstreams,
not as an asset.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: