>>>>> "Victor" == Victor Wagner <[EMAIL PROTECTED]> writes:
>> предлагая и, главное, не делая ничего своего. На мое письмо с вполне
>> конкретным вопросом о пользе одноименных многоверсионных пакетов вы
>> мне, надо отметить, так и не ответили.
Victor> Попробую ответить:
Victor> Расмотрим, например такой пакет как tcl. Он включает в себя
Victor> разделяемую библиотеку, и всякие разные приложения, использующие
Victor> tcl как встроенный язык (вплоть до Python/Tkinter) имеют привычку
Victor> к этой библиотеке линковаться.
Victor> Вплоть до версии 8.2 API был бинарно (а часто и на уровне
Victor> исходников) не слишком совместим. Дальше появились stubs и стало
Victor> проще.
Victor> А сейчас мы имеем два пакета - tcl8.0 и tcl8.2, причем есть
Victor> пакеты, например tkstep, которые с версией 8.0 работать будут, а
Victor> на версию 8.2 их еще не портанули.
Victor> Собственно, я держу оба пакета и использую tclsh8.0 в тех случаях
Victor> когда мне нужно выводить в Postscript или пересылать через
Victor> clipboard русские тексты, и tclsh8.2, когда мне нужно
Victor> конвертировать кодировки внутри скрипта.
Я про это все в курсе, и держу обе версии по очень схожим
причинам. Я спрашивал несколько об ином -- вот цитата:
>-----------------------
VicVis> Напишу еще раз и не мылом: 1. Нет возможности установить один
VicVis> и тот же пакет разных версий. Именно по этому мы имеем такую
VicVis> дурость как:
VicVis> Package: tk8.0 Version: 8.0
VicVis> Package: tk8.3 Version: 8.3
VicVis> Вместо
VicVis> Package: tk Version: 8.0
VicVis> Package: tk Version: 8.3
VicVis> хотя многие пакеты разных версий прекрасно могут
VicVis> сосуществовать друг с другом. А так сколько всякой фигни в
VicVis> дистрибутивах типа libgtk1.0, libgtk1.1 libgtk1.2, zlib1g, zlib и
VicVis> т.д. т.е. по сути дела разные версии одного и того же пакета имеют
VicVis> разные названия
"Дурость" -- это эмоции. Объясните, пожалуйста, конкретные выгоды
от реализации возможности держать два разных пакета под одним
именем. libgtk1 и libgtk1.2, к примеру -- это достаточно разные версии
одной библиотеки, чтобы программа, собранная с одной версией, не могла
работать под другой. И выгоды -- будет меньше показываться в dselect?
Да нет, просто вместо tk8.0, tk8.2, tk8.3 будет показываться tk, tk,
tk; и даже не знаю, что более неудобно. А вот проблемы я себе могу ясно
представить -- дистрибутив будет трясти не один месяц. Чего ради?
>-----------------------
Victor> Аналогичный эффект наблюдается практически с любыми
Victor> библиотеками. Вспомним хотя бы libc5/glibc.
Да, конечно, хорошо было бы, как в аиксе, иметь возможность ставить
две версии одного и того же пакета -- как минимум для того, чтобы
коммитить или отменять установку (характерный пример -- libc6 2.2.3-10
пришла сломаной при сборке, в результате чего с ней, например, не
работает vmware -- я бы очень хотел иметь возможность автоматически
откатиться на предыдущую версию; либо закоммитить установку новой с
автоматическим удалением предыдущей). Более того -- я знаю, что есть
попытки сделать новый packet manager с подобными свойствами (см.,
например, проект SWIM). Сделают -- дай-то Бог, дождусь, пока оно станет
живым (а на домашней машине -- так и раньше поставлю: помочь) -- и
перейду. А до тех пор: dpkg -- отличная работа, низкий поклон авторам;
и хорошо, что у них хватает ума не пытаться делать сейчас революций.
Приведенные же примеры -- они, в общем, неудачны: libgtk1 и
libgtk1.2, ровно как и tk8.0 и tk8.2 -- разные пакеты; по своим
свойствам и списку совместимого софта -- разные. Делать революцию
только для того, чтобы они назывались одинаково (и все удобство?) --
смысла не вижу никакого.
--
Alexey V. Naidyonov
