Comments 9
Проблема не нова, см. статью о пакетных менеджерах. Большинство популярных языков уже не используют пакетный менеджер дистрибутива для разработки, что приводит к постоянному отставанию последних. Скорее, удивляет, что с 2017 года дело не сдвинулось с мёртвой точки.
Debian и k8s стоят на вершине горы, а внизу пасётся код.
k8s предлагает Debian:
- Слушай, давай быстренько-быстренько завендорим всё, релизнем новую версию и быстренько-быстренько объявим её устаревшей!
- Не-ет !
- Ну, тогда давай быстренько-быстренько завендорим 200 пакетов, релизнем две версии и быстренько-быстренько объявим их устаревшими!
- Не-ет !
- Ну, а что же тогда ты предлагаешь ?
- Мы медленно-медленно запакетируем все библиотеки, всё протестируем, и будем поддерживать дистрибутив стабильным даже после того, как k8s объявят obsolete.
такими действиями они открывают дверку в мир того, что дебиан станет помойкой и для всего остального и его сами пользователи прикопают… М-да. Пойду-ка я получше почитаю оригинальную новость, потому что парадокс в том, что сам куб — это несколько бинарников и конфигов БЕЗ внешних зависимостей, следовательно, проблема с пакетированием возможна только для исходников.
amarao что скажешь?
Debian действует в рамках общественной пользы (public interest). Вендоринг полезен для ускорения конкретного проекта, но вреден в целом для дистрибутива (если у вас каждый бинарь будет вендорить всё, то у вас на каждый ls будет по своей libc) — у вас будут толстые бинари с неизвестными библиотеками внутри и произвольной полисей.
Задачи, которые решает Дебиан весьма обширны. Например, они решили проблему переезда с python2 на python3 таким образом, чтобы всё продолжало работать. Даже то, что не должно было работать в условиях переезда.
Проект про reproducible builds уже практически завершён, и сейчас команда энтузиастов работает на bootstrap seed (trusting the trust problem).
В целом по вопросу: куб хочет вендорить. Политика дебиана в общем случае требует, чтобы вендоринга не было. Кубу сделали исключение — плохое исключение. В силу эгоистической позиции компании-разработчика в этом продукте это исключение приходится терпеть.
Раньше особыми источниками боли были php'шные софтинки (которые хотели config.php иметь в каталоге с кодом, да ещё и с правом записи в него из index.php), была боль с многими erlang'овыми приложениями, которые хотели вендорить свой beam.smp. Теперь к ним добавился ещё и k8s.
Но куб — микроскопическая часть всего того, что есть в дебиане, и хипстеры, которые считают, что "или куб, или смерть" — посмотрите на докер.
March 20, 2013 — Docker initial release.
May 2013 — Дебиан релизит Wheezy с поддержкой multiarch'а.
Jul 2019 — Дебиан релизит Buster, в котором примерно 90% reproducible build
Nov 2019 — Мирантис покупает осмысленную часть докера, а его свармы почти мертвы из-за k8s, да и сам докер доедают runc и containerd.
2021 (наверное) — Debian релизит Bullseye
Докер пришёл и ушёл а Дебиан остался. Почему в отношении k8s надо предполагать что-то другое?
В целом по вопросу: куб хочет вендорить. Политика дебиана в общем случае требует, чтобы вендоринга не было. Кубу сделали исключение — плохое исключение. В силу эгоистической позиции компании-разработчика в этом продукте это исключение приходится терпеть.
проблема не в том, что куб вендорит — ЛЮБОЙ ПРОДУКТ НАПИСАННЫЙ на ГОЛАНГ — вендорит. И ничего — никто не умер.
Я уж не говорю о том, что нефиг кубернетес тащить на дебиан. Никакой ценности ставить дебиан, чтобы сделать из него платформу для куба — нет. Хочешь куб — тащи любой специализированный дистрибутив линукса (с минимальным footprint), либо бери куб как коробку (=openshift)
Да, язык выбрал не очень хорошую модель. Однако, для общего случая, дебиан прекрасно справляется с -dev зависимостями.
apt search ^golang-|wc -l
4511Более того, для наших inhouse приложений на го мы прекрасно используем инфраструктуру дебиана для сборки (включая эти самые -dev пакеты). Мне пришлось допакетировать три библиотеки, но всё остальное есть в апстриме.
В этом смысле модель debian вполне может жить с гошной. Это не отменяет того, что авторы могут захотеть странного и от них будет боль, но в общем случае — вполне.
Я в принципе не понимаю зачем упаковывать гошные библиотеки в отдельные dpkg пакеты, это же не питон с его глобальным site packages (да, есть и user site packages но софт из apt его не использует).
Люди перешли на go modules и го сам подтянет пакеты при сборке, а старые проекты полагаются на gopath который уникален для каждого пользователя.
В результате репа Debian забита ненужными пакетами с странными длинными именами в духе golang-github-com-username-libname
Теперь в Debian комфортнее работать с k8s. Сопровождающий добавил 200 зависимостей и вынудил комитет одобрить монолит