Re: [devel] I: новый libssl7

["Alexander Bokovoy" <ab@altlinux.org>]

2008/8/9 Evgeny Sinelnikov <sin@altlinux.ru>:
>>> бинарно несовместим с текущей сборкой в Сизифе. На текущий момент
>>> библиотека предоставляется пакетом libssl6. Этот пакет планируется
>>> сохранять неграничено долго. Но новые сборки будут проводится на
>>> libssl7.
>> А libssl6 -- это то, что нужно сторонним (проприетарным) пакетам,
>> собранным с текущим openssl?
>
> Вероятно, я не знаю таких, ибо пользоваться пока не приходилось. Но
> работать они всё равно будут.
Еще раз. Меняется ABI в системообразующем пакете. Хотелось бы
убедиться, что в Сизифе останутся средства для работы существующих
приложений вроде Opera, Google Earth/Google desktop, etc. Сизиф ради
Сизифа бессмысленен, поэтому к любому пакету, который является
существенным для работы, можно предъявить подобные требования по
сохранению совместимости. Я хочу только убедиться, что стратегия
обновления продумана и не создаст проблем с типичными популярными
приложениями из-за пределов Сизифа.

>> Каком срок предыдущей жизни soname? Дело
>
> Это вопрос к разработчикам openssl. Впрочем это не повод не обновлять
> библиотеку, отвечающую за безопасность.
См. выше. Я не собираюсь ограничивать возможности по обновлению, а
задаю вопрос по реализации поддержки работоспособности существующих
программ. Например, если существующее ABI было стабильным в течение
последних 2-3 лет, то на период около года имеет смысл предоставить
его в виду совместимого ABI (libssl6 или как в случае с stdc++и
компиляторами -- stdc++-compat). Вопрос не в том, что обновлять, а что
-- нет, вопрос в проработанной стратегии стабильности и
предсказуемости среды.

Хотелось бы видеть от любого мейнтейнера, который планирует обновление
ABI в Сизифе и который знает, что его изменение повлияет на других,
иметь такую проработанную стратегию сохранения работоспособности
приложений с предыдущей версией ABI. В идеале такой подход позволил бы
сохранить стабильный и предсказуемый взгляд на платформу при
достаточной гибкости ее развития. Замечу, что речь не идет о том, что
везде следует выставлять костыли в виде -compat, но разумный
компромисс должен все-таки быть.

>> Можно составить список пакетов, которые перестанут собираться? Если их
>> количество исчисляется десятком, то было бы неплохо перед отправкой
>> libssl7 озаботиться помощью мейнтейнерам в виде патчей в багзиллу.
> Список пакетов, который нужно пересобрать я приводил. Если бы там была
> пара пакетов, то я бы у же и их исправил. Для некоторых мы так и
> сделали, но 159 пакетов - это уже много. Вообще я думаю, что Сизиф
Это пакеты, которые нужно пересобрать, а не пакеты, которые сломаются
однозначно из-за изменений в API.

> нужен именно в таких случаях, когда без централизованной сборки уже не
> обойтись. Иначе, если сделать как вы предлагаете, я вынужден держать
> свой форк Сизифа. Только вот если я сам на все пакеты патчи буду
> накладывать, то это уже будет не Сизиф, а нечто вроде собственного
> репозитория. С таким подходом можно и при обновлении gcc, например до
> версии 4.3.X, потребовать пересобрать все ломающиеся пакеты и
> предоставить нужные патчи.
Нет, говорю я совсем не об этом. См. выше.

>>> Если ранее отсутствие этого не влияло, то сейчас приведёт к
>>> несобираемости таких пакетов. В нашем случае могут перестать
>>> собираться даже те пакеты, которые нормально могли бы быть собраны в
>>> Fedora, где заголовочные файлы kerberos лежат в /usr/include, а не
>>> вынесены в /usr/include/krb5, как у нас.
>> Я считаю, что "вынос" в /usr/include/krb5 правилен -- нам еще heimdal
>> содержать в скором будущем.
>
> Но вот и ответ - та самая доля разумности, которая так неочевидна на
> первый взгляд.
Это решение было принято еще в 2001 году, когда собирались первые
версии для ALT этого пакета.

-- 
/ Alexander Bokovoy