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

[amarao_san]

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

Comments

[cottidianus]

выше 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
/usr
/usr/bin
/usr/bin/libusb-config
/usr/lib64
/usr/lib64/debug
/usr/lib64/debug/usr
/usr/lib64/debug/usr/lib64
/usr/lib64/debug/usr/lib64/libusbpp-0.1.so.4.4.4.debug
/usr/lib64/debug/usr/lib64/libusb-0.1.so.4.4.4.debug
/usr/lib64/libusb-0.1.so.4 -> libusb-0.1.so.4.4.4
/usr/lib64/libusb.so -> libusb-0.1.so.4.4.4
/usr/lib64/libusb.la
/usr/lib64/libusbpp-0.1.so.4 -> libusbpp-0.1.so.4.4.4
/usr/lib64/libusbpp.so -> libusbpp-0.1.so.4.4.4
/usr/lib64/libusbpp.la
/usr/lib64/libusb.a
/usr/lib64/libusbpp.a
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/libusb.pc
/usr/lib64/libusb-0.1.so.4.4.4
/usr/lib64/libusbpp-0.1.so.4.4.4
/usr/include
/usr/include/usbpp.h
/usr/include/usb.h
$ cave contents libusb:1
/usr
/usr/lib64
/usr/lib64/libusb-1.0.so.0.1.0
/usr/lib64/libusb-1.0.so.0 -> libusb-1.0.so.0.1.0
/usr/lib64/libusb-1.0.so -> libusb-1.0.so.0.1.0
/usr/lib64/libusb-1.0.la
/usr/lib64/libusb-1.0.a
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/libusb-1.0.pc
/usr/lib64/debug
/usr/lib64/debug/usr
/usr/lib64/debug/usr/lib64
/usr/lib64/debug/usr/lib64/libusb-1.0.so.0.1.0.debug
/usr/include
/usr/include/libusb-1.0
/usr/include/libusb-1.0/libusb.h

обе библиотеки установлены и прекрасно живут рядом друг с другом
$ pkg-config --libs --cflags libusb-1.0
-I/usr/include/libusb-1.0 -lusb-1.0
$ pkg-config --libs --cflags libusb
-lusb

[amarao_san]

Круто, я рад, что хотя бы для си вопросы библиотек решили.

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

[ext_1177827]

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

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

[amarao_san]

Иметь питон 2.7 и 2.6 одновременно, или независимые модули нескольких версий для одной версии питона? Feel the difference.

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

[ext_1177827]

А кому вдруг понадобилась версионность модулей питона? Кажется, даже родной pip такое не умеет, а если умеет, то превратит все в зоопарк версий.