On Tue, Feb 02, 2010 at 05:39:51PM +0300, Dmitry V. Levin wrote: > On Tue, Feb 02, 2010 at 07:33:04PM +0500, Andrey Rahmatullin wrote: > > On Tue, Feb 02, 2010 at 05:23:39PM +0300, Dmitry V. Levin wrote: > > > On Tue, Feb 02, 2010 at 06:42:56PM +0600, Alexey Morozov wrote: > > > > В сообщении от Вторник 02 февраля 2010 18:19:15 автор Dmitry V. Levin написал: > > > > > Применительно к нашим условиям: > > > > > - автоматически добавлять %ghost %verify(not size md5 mtime) к pyc- и > > > > > pyo-файлам относительно несложно; > > > > > - реализовать post-transaction filetrigger, который будет воссоздавать > > > > > эти файлы, тоже относительно несложно; > > > > > - бинарных пакетов, слинкованных с libpython2.6.so.1.0, сейчас в Сизифе > > > > > 322 штуки (не считая python-modules-*), и от "binary NMUs" при каждой > > > > > смене "default Python version" всё равно, видимо, никуда не деться. > > > > > > > > > > Вот из-за этих 322 пакетов, которые слинкованы с "default Python version", > > > > > и не получается более одного полноценного питона в репозитории. > > > > > > > > А зачем нужно принудительно переводить всех на default Python version? В > > > > дебиановском репозитории (Lenny) совершенно спокойно соседствуют те, кому > > > > нужен python2.4, и те, кто завязан на python2.5. Могу списочки приложить, но > > > > они длинные (62 rdepend на 2.4 и 141 - на 2.5) > > > > > > А как же это работает, когда приложению нужно 2 модуля, которые слинкованы > > > с разными версиями python? > > > > > Они не линкуются с libpython. > > А чем тогда гарантируется совместимость модуля с питоном, под который он > был собран? Видимо, вопрос оказался слишком сложным, попробую переформулировать. Eсли не все extension modules переводятся на default version единовременно, то как быть с теми пакетами, которым нужно два разных extension modules, собранных под разные питоны? Какой механизм выявляет всех таких клиентов в репозитории, чем этот механизм принципиально отличается от нашего механизма зависимостей вида pythonN.M(module)? -- ldv