Исправление DRVTiny, (текущая версия) :
Противоречия прямого, может быть, и нет, но есть проблема разумной достаточности. Если твоя компания наклепала 200 приложений, из которых 90 используют boost - нужно либо паковать в rpm/deb, где boost - зависимость, и полагаться на разработчиков дистрибутива, либо заниматься геморроем самостоятельно и делать свой действительно docker-дистрибутив, где boost будет базовым контейнером/базовым слоем, от которого зависят другие контейнеры.
Я не вижу никакой проблемы с дистрибутивами, особенно сейчас, когда они благодаря тому же systemd весьма неплохо унифицированы, но если собрать пакеты аж в 2-х разных форматах столь сложно - делайте свой docker-registry, где приложения всё-таки это приложения, а библиотеки - это библиотеки. С точки зрения разработчиков, они же умные люди, должно быть понятно, что приложения и библиотеки, тем более не свои вообще библиотеки, - это разные множества, и пересекать их можно разве что тогда, когда бизнес имеет сугубо «сиюминутный» характер, а в качестве методологии разработки принят принцип ХХП.
При этом ни один серьёзный заказчик не примет от вас контейнер, в котором упакована библиотека, за обновление которой никто вообще не отвечает.
В лучшем случае умный заказчик включит в договор что-то вроде «в случае обнаружения уязвимостей в поставляемом ПО, вы обязаны исправить эти уязвимости в течение N часов».
Зачем разработчику ПО подписываться ещё и на то, чтобы содержать стороннее ПО на стороне заказчика в актуальном состоянии? И даже если это так интересно, то почему в случае такой необходимости разработчику должно быть удобнее пересобрать и выложить не один контейнер, а 90 контейнеров? Это такая форма мазохизма или традиционный русский «авось» (сейчас мне вот так по-идиотски сделать удобно - а потом, может, вообще кризис грянет и мы все умрём)?
Исходная версия DRVTiny, :
Противоречия прямого, может быть, и нет, но есть проблема разумной достаточности. Если твоя компания наклепала 200 приложений, из которых 90 используют boost - нужно либо паковать в rpm/deb, где boost - зависимость, и полагаться на разработчиков дистрибутива, либо заниматься геморроем самостоятельно и делать свой действительно docker-дистрибутив, где boost будет базовым контейнером/базовым слоем, от которого зависят другие контейнеры.
Я не вижу никакой проблемы с дистрибутивами, особенно сейчас, когда они благодаря тому же systemd весьма неплохо унифицированы, но если собрать пакеты аж в 2-х разных форматах столь сложно - делайте свой docker-registry, где приложения всё-таки это приложения, а библиотеки - это библиотеки. С точки зрения разработчиков, они же умные люди, должно быть понятно, что приложения и библиотеки, тем более не свои вообще библиотеки, - это разные множества, и пересекать их можно разве что тогда, когда бизнес имеет сугубо «сиюминутный» характер, а в качестве методологии разработки принят принцип ХХП.
При этом ни один серьёзный заказчик не примет от вас контейнер, в котором упакована библиотека, за обновление которой никто вообще не отвечает.
В лучшем случае умный заказчик включит в договор что-то вроде «в случае обнаружения уязвимостей в поставляемом ПО, вы обязаны исправить эти уязвимости в течение N часов».
Зачем разработчику ПО подписываться ещё и на то, чтобы содержать стороннее ПО на стороне заказчика в актуальном состоянии? И даже если это так интересно, то почему в случае такой необходимости разработчику должно быть удобнее пересобрать и выложить не один конейнер, а 90 контейнеров? Это такая форма мазохизма?