[devel] I: новый libssl7

[Evgeny Sinelnikov]

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

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

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

Этот вопрос ставился первоначально и конечно предусмотрен.

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

Совершенно верно. Библиотека libssl6 сохранится и будет собираться из
пакета openssl098d. Иного костыля пока придумать не удалось. К тому же
это обкатанный костыль, который сохраняет libssl4 в Сизифе и по сей
день. Вообще странно... Я же про это сразу написал...

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

На уровне API, если я всё правильно понимаю, openssl-0.9.8d и
openssl-0.9.8h совместимы полностью. Смена сонейма связана со
структурами данных изменяющими ABI. Так что сломаться могут пакеты не
по причине не совместимости, а по причине не корректной установки
CFLAGS, а именно -I/usr/include/krb5, что привнесено поддержкой
kerberos в новой сборке openssl.

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


-- 
Sin (Sinelnikov Evgeny)