Выписываю свои первые мысли по вопросу. У меня нет ещё готовой точки зрения и я хочу просто пока что сформулировать проблему и аргументы с каждой из точек зрения
( Read more... )
Подружить эти миры в текущем виде могут только chroot + aufs.
Но опять же, мир РАЗРАБОТЧИКА наверное нельзя изменить. В том смысле, что поскольку разработка сторонних пакетов часто ломает обратную совместимость, то либо у него всё превращается в лотерею, либо он четко прописывает зависимости от старого софта. То есть в том, что всё так сделано, даже не совсем его вина, разве что, вина их всех разом, но это нерешаемо.
По пути "chroot + aufs" пошли в Windows (всякие там http://msdn.microsoft.com/en-us/library/aa376307.aspx), и к какой-то гармонии пришли, но на Windows слабо используется совсем уж неявное связывание в стиле просто "зовем ruby с командной строки"; как позвать разные ruby для разных приложений, данный метод умалчивает.
"Однако, есть и противоположная позиция - позиция разработчика. У него - миллион и одна зависимость."
У тебя в ОС тоже миллион и одна зависимость. :) Все то же самое, только у твоей конторы не так много ресурсов чтобы перепиливать часть софта чтобы зависеть от одной версии сторонней библиотеки. (Что-то написали - оно работает, зачем трогать?). Брать старые версии софта тоже плохо (какие старые версии? у нас же свой софт - он вообще bleeding edge должен быть :) Это не проблема, если у софта все зависимости внутри (кроме размера, траты памяти из-за плохого кэширования...).
Думаю, нужен механизм выковыривания из яиц зависимостей от библиотек, и, как следствие, пэкаджей. Видимо, его придется пилить для каждого яйца специально и руками (если такое вообще возможно). Выковыривать версии при сборке, сравнивать с тем что есть в системе (или неконфликтно может быть) и, незнаю, ругаться.
Хотя, лучше всего, эту проблему постараться убить в зародыше организацией процесса разработки (фиксировать зависимости, что бы были одинаковые для всех,
Выравнивать всех под одну гребёнку - червато и недобро. В первую очередь, потому что если мы фиксируем всем какую-то версию, должен быть и регламент бампа этой версии.
А "регламент бампа" это вечная борьба тех, кому всё хорошо и менять не хочется, и теми, кому надо поменять. Чем более всеобщий барьер - тем больше вокруг него склок (вспомни libffi5-6, да?).
Процесс "самим пакетировать все версии" - во-первых не бесплатен (кто-то должен пойти, поднять свою задницу и всё это пакетировать, вместо того, чтобы код/тесты писать), во-вторых всё равно не решает проблемы сосуществования разных версий библиотек.
Насколько я знаю, у питона с этим всегда бобо было, но мне показали рубёвый bundler и я не могу не признать, что его схема выглядит разумно.
Впрочем, я не все аргументы и проблемы выписал. По мере появления мыслей, буду выписывать. потом можно будет систематизировать и попытаться найти точное описание конфликтных точек.
Да, разумеется, с бампом, да, как и во многих вопросах, нужен консенсус. Ничего не поделаешь. Просто надо ответственее бампать, с оценкой, c выделением времени всех затрагиваемых программистов, в нужное время, а не внезапно за/перепилить какой-то софт, потом сказать остальным "обновляйте свое говно сами, фигли" (если я правильно помню историю с libffi. Я в ней, вроде, не участвовал
( ... )
Вся проблема в стоимости консенсуса. Точнее, в соотношении "цена консенсуса/польза для проекта".
Консенсус - это когда все стороны договора остаются одинаково недовольными. Иными словами - это взаимные уступки и самоограничения.
Так что баланс получается спорный. С одной стороны мы имеем кучу разработчиков, каждый из которых хотел бы иметь ту версию, которая сейчас (просто потому, что адаптировать под другую версию без нужды - это терять время, даже если всё остальное намертво тестами покрыто). А с другой, что мы получаем взамен, кроме банального "ура, дебки всюду"?
Кстати, история с libffi крайне показательная, потому что если принять за константу число воркеров в CI, то какая-то из сторон должна была поступиться в сторону debian/ubuntu, или согласиться с установкой libc из sid'а. Со всех точек зрения это была бы глупость.
При этом в режиме "всё своё с собой" есть проблемы. Попробую додумать/выписать чуть позже.
> Однако, есть и противоположная позиция - позиция разработчика. У него - миллион и одна зависимость. Он использует кучу библиотек из pypy, rubygems, epel, hackage, opam и т.д. На сервере могут одновременно работать программы, которым нужна одна и та же библиотека, но с разными версиями. Например, одному нужна libfoo [>1.5, <2], другому libfoo [>2]. вы хотите слоты: http://devmanual.gentoo.org/general-concepts/slotting/
Это не моё личное мнение, а реальность. Покажи мне хоть один энтерпрайзнутый продукт на 3-10+ серверов, у которого бы в рекомендуемых ОС была гента. Я таких не знаю. Зато знаю, что много центоса и (усилиями опенстека) бубунты.
В debian или rhel - нет, не решили. В gentoo - решили сто лет назад. Иметь в системе одновременно при необходимости python 2.7 и 3.2, ruby 1.8 и 2.0, да даже php 5.4 и 5.5 - нормальная практика, решенная с помощью слотов.
Если ты - разработчик, тебя не должно волновать, что там у пользователя. При подходе разработчик - мантейнер дистрибутива - пользователь, при выходе новой версии и ломке зависимости голова должна болеть у мантейнера (это его основное занятие). Некоторые разработчики, считая себя самыми умными, думают, что запросто могут сделать deb или rpm, однако только делают себе же хуже, взваливая несвойственную себе задачу мантейнера.
Comments 28
Но опять же, мир РАЗРАБОТЧИКА наверное нельзя изменить. В том смысле, что поскольку разработка сторонних пакетов часто ломает обратную совместимость, то либо у него всё превращается в лотерею, либо он четко прописывает зависимости от старого софта.
То есть в том, что всё так сделано, даже не совсем его вина, разве что, вина их всех разом, но это нерешаемо.
По пути "chroot + aufs" пошли в Windows (всякие там http://msdn.microsoft.com/en-us/library/aa376307.aspx), и к какой-то гармонии пришли, но на Windows слабо используется совсем уж неявное связывание в стиле просто "зовем ruby с командной строки"; как позвать разные ruby для разных приложений, данный метод умалчивает.
Reply
У тебя в ОС тоже миллион и одна зависимость. :) Все то же самое, только у твоей конторы не так много ресурсов чтобы перепиливать часть софта чтобы зависеть от одной версии сторонней библиотеки. (Что-то написали - оно работает, зачем трогать?). Брать старые версии софта тоже плохо (какие старые версии? у нас же свой софт - он вообще bleeding edge должен быть :) Это не проблема, если у софта все зависимости внутри (кроме размера, траты памяти из-за плохого кэширования...).
Думаю, нужен механизм выковыривания из яиц зависимостей от библиотек, и, как следствие, пэкаджей. Видимо, его придется пилить для каждого яйца специально и руками (если такое вообще возможно). Выковыривать версии при сборке, сравнивать с тем что есть в системе (или неконфликтно может быть) и, незнаю, ругаться.
Хотя, лучше всего, эту проблему постараться убить в зародыше организацией процесса разработки (фиксировать зависимости, что бы были одинаковые для всех,
Reply
А "регламент бампа" это вечная борьба тех, кому всё хорошо и менять не хочется, и теми, кому надо поменять. Чем более всеобщий барьер - тем больше вокруг него склок (вспомни libffi5-6, да?).
Процесс "самим пакетировать все версии" - во-первых не бесплатен (кто-то должен пойти, поднять свою задницу и всё это пакетировать, вместо того, чтобы код/тесты писать), во-вторых всё равно не решает проблемы сосуществования разных версий библиотек.
Насколько я знаю, у питона с этим всегда бобо было, но мне показали рубёвый bundler и я не могу не признать, что его схема выглядит разумно.
Впрочем, я не все аргументы и проблемы выписал. По мере появления мыслей, буду выписывать. потом можно будет систематизировать и попытаться найти точное описание конфликтных точек.
Reply
Reply
Консенсус - это когда все стороны договора остаются одинаково недовольными. Иными словами - это взаимные уступки и самоограничения.
Так что баланс получается спорный. С одной стороны мы имеем кучу разработчиков, каждый из которых хотел бы иметь ту версию, которая сейчас (просто потому, что адаптировать под другую версию без нужды - это терять время, даже если всё остальное намертво тестами покрыто).
А с другой, что мы получаем взамен, кроме банального "ура, дебки всюду"?
Кстати, история с libffi крайне показательная, потому что если принять за константу число воркеров в CI, то какая-то из сторон должна была поступиться в сторону debian/ubuntu, или согласиться с установкой libc из sid'а. Со всех точек зрения это была бы глупость.
При этом в режиме "всё своё с собой" есть проблемы. Попробую додумать/выписать чуть позже.
Reply
вы хотите слоты: http://devmanual.gentoo.org/general-concepts/slotting/
Reply
Reply
Reply
Reply
$ 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
А вот для питона и руби - нет.
Reply
Если ты - разработчик, тебя не должно волновать, что там у пользователя. При подходе разработчик - мантейнер дистрибутива - пользователь, при выходе новой версии и ломке зависимости голова должна болеть у мантейнера (это его основное занятие). Некоторые разработчики, считая себя самыми умными, думают, что запросто могут сделать deb или rpm, однако только делают себе же хуже, взваливая несвойственную себе задачу мантейнера.
Reply
Сосуществование питонов разных версий в дебиане и rhel'е решили.
Reply
Reply
Reply
Leave a comment