Концептуальная проблема с пакетами в системе (devops)

Nov 25, 2013 03:48

Выписываю свои первые мысли по вопросу. У меня нет ещё готовой точки зрения и я хочу просто пока что сформулировать проблему и аргументы с каждой из точек зрения ( Read more... )

rpm, devops, packet manager, deb

Leave a comment

Comments 28

dmih November 25 2013, 00:22:20 UTC
Подружить эти миры в текущем виде могут только chroot + aufs.

Но опять же, мир РАЗРАБОТЧИКА наверное нельзя изменить. В том смысле, что поскольку разработка сторонних пакетов часто ломает обратную совместимость, то либо у него всё превращается в лотерею, либо он четко прописывает зависимости от старого софта.
То есть в том, что всё так сделано, даже не совсем его вина, разве что, вина их всех разом, но это нерешаемо.

По пути "chroot + aufs" пошли в Windows (всякие там http://msdn.microsoft.com/en-us/library/aa376307.aspx), и к какой-то гармонии пришли, но на Windows слабо используется совсем уж неявное связывание в стиле просто "зовем ruby с командной строки"; как позвать разные ruby для разных приложений, данный метод умалчивает.

Reply


ikkeps November 25 2013, 00:29:36 UTC
"Однако, есть и противоположная позиция - позиция разработчика. У него - миллион и одна зависимость."

У тебя в ОС тоже миллион и одна зависимость. :) Все то же самое, только у твоей конторы не так много ресурсов чтобы перепиливать часть софта чтобы зависеть от одной версии сторонней библиотеки. (Что-то написали - оно работает, зачем трогать?). Брать старые версии софта тоже плохо (какие старые версии? у нас же свой софт - он вообще bleeding edge должен быть :) Это не проблема, если у софта все зависимости внутри (кроме размера, траты памяти из-за плохого кэширования...).

Думаю, нужен механизм выковыривания из яиц зависимостей от библиотек, и, как следствие, пэкаджей. Видимо, его придется пилить для каждого яйца специально и руками (если такое вообще возможно). Выковыривать версии при сборке, сравнивать с тем что есть в системе (или неконфликтно может быть) и, незнаю, ругаться.

Хотя, лучше всего, эту проблему постараться убить в зародыше организацией процесса разработки (фиксировать зависимости, что бы были одинаковые для всех,

Reply

amarao_san November 25 2013, 01:07:38 UTC
Выравнивать всех под одну гребёнку - червато и недобро. В первую очередь, потому что если мы фиксируем всем какую-то версию, должен быть и регламент бампа этой версии.

А "регламент бампа" это вечная борьба тех, кому всё хорошо и менять не хочется, и теми, кому надо поменять. Чем более всеобщий барьер - тем больше вокруг него склок (вспомни libffi5-6, да?).

Процесс "самим пакетировать все версии" - во-первых не бесплатен (кто-то должен пойти, поднять свою задницу и всё это пакетировать, вместо того, чтобы код/тесты писать), во-вторых всё равно не решает проблемы сосуществования разных версий библиотек.

Насколько я знаю, у питона с этим всегда бобо было, но мне показали рубёвый bundler и я не могу не признать, что его схема выглядит разумно.

Впрочем, я не все аргументы и проблемы выписал. По мере появления мыслей, буду выписывать. потом можно будет систематизировать и попытаться найти точное описание конфликтных точек.

Reply

ikkeps November 25 2013, 03:13:09 UTC
Да, разумеется, с бампом, да, как и во многих вопросах, нужен консенсус. Ничего не поделаешь. Просто надо ответственее бампать, с оценкой, c выделением времени всех затрагиваемых программистов, в нужное время, а не внезапно за/перепилить какой-то софт, потом сказать остальным "обновляйте свое говно сами, фигли" (если я правильно помню историю с libffi. Я в ней, вроде, не участвовал ( ... )

Reply

amarao_san November 25 2013, 03:39:42 UTC
Вся проблема в стоимости консенсуса. Точнее, в соотношении "цена консенсуса/польза для проекта".

Консенсус - это когда все стороны договора остаются одинаково недовольными. Иными словами - это взаимные уступки и самоограничения.

Так что баланс получается спорный. С одной стороны мы имеем кучу разработчиков, каждый из которых хотел бы иметь ту версию, которая сейчас (просто потому, что адаптировать под другую версию без нужды - это терять время, даже если всё остальное намертво тестами покрыто).
А с другой, что мы получаем взамен, кроме банального "ура, дебки всюду"?

Кстати, история с libffi крайне показательная, потому что если принять за константу число воркеров в CI, то какая-то из сторон должна была поступиться в сторону debian/ubuntu, или согласиться с установкой libc из sid'а. Со всех точек зрения это была бы глупость.

При этом в режиме "всё своё с собой" есть проблемы. Попробую додумать/выписать чуть позже.

Reply


cottidianus November 25 2013, 03:21:30 UTC
> Однако, есть и противоположная позиция - позиция разработчика. У него - миллион и одна зависимость. Он использует кучу библиотек из pypy, rubygems, epel, hackage, opam и т.д. На сервере могут одновременно работать программы, которым нужна одна и та же библиотека, но с разными версиями. Например, одному нужна libfoo [>1.5, <2], другому libfoo [>2].
вы хотите слоты: http://devmanual.gentoo.org/general-concepts/slotting/

Reply

amarao_san November 25 2013, 04:00:44 UTC
Использование gentoo на серверах в продакшене не является best practice. Уносите.

Reply

ext_789521 November 25 2013, 05:08:22 UTC
Это лишь Ваше личное мнение, не являющееся истиной в последней инстанции...

Reply

amarao_san November 25 2013, 08:56:57 UTC
Это не моё личное мнение, а реальность. Покажи мне хоть один энтерпрайзнутый продукт на 3-10+ серверов, у которого бы в рекомендуемых ОС была гента. Я таких не знаю. Зато знаю, что много центоса и (усилиями опенстека) бубунты.

Reply


cottidianus November 25 2013, 03:31:51 UTC
выше replies disabled, поэтому пишу здесь

$ cave show -n libusb::installed
* dev-libs/libusb::installed
::installed 0.1.12 {:0.1} 1.0.9-r1 {:1}
dev-libs/libusb-0.1.12:0.1::installed
dev-libs/libusb-1.0.9-r1:1::installed

установлено две версии одной и той же библиотеки
$ cave contents libusb:0.1 ( ... )

Reply

amarao_san November 25 2013, 04:02:59 UTC
Круто, я рад, что хотя бы для си вопросы библиотек решили.

А вот для питона и руби - нет.

Reply

ext_1177827 November 25 2013, 08:41:35 UTC
В debian или rhel - нет, не решили. В gentoo - решили сто лет назад. Иметь в системе одновременно при необходимости python 2.7 и 3.2, ruby 1.8 и 2.0, да даже php 5.4 и 5.5 - нормальная практика, решенная с помощью слотов.

Если ты - разработчик, тебя не должно волновать, что там у пользователя. При подходе разработчик - мантейнер дистрибутива - пользователь, при выходе новой версии и ломке зависимости голова должна болеть у мантейнера (это его основное занятие). Некоторые разработчики, считая себя самыми умными, думают, что запросто могут сделать deb или rpm, однако только делают себе же хуже, взваливая несвойственную себе задачу мантейнера.

Reply

amarao_san November 25 2013, 08:59:34 UTC
Иметь питон 2.7 и 2.6 одновременно, или независимые модули нескольких версий для одной версии питона? Feel the difference.

Сосуществование питонов разных версий в дебиане и rhel'е решили.

Reply


blackyblack November 25 2013, 04:19:39 UTC
Решаемо, если все сошки и все пакеты версионированы и не удаляются из системы до тех пор, пока на них есть хотя бы одна ссылка.

Reply

u_magistr November 25 2013, 04:42:44 UTC
именно так и сделаны слоты в генте )

Reply


Leave a comment

Up