[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian tcl policy: есть ли мысли?



Здравствуйте, народ.

Тут у меня возникла тревога за дальнейшую судьбу tcl в debian.  Грубо
говоря, явно намечается некоторый бардак (я тут дебианизировал tkhtml,
и для этого изучал, как собираются другие расширения).

Первый ужас в том, что tcl сканирует все подкаталоги /usr/lib в
поисках pkgIndex'ов (впрочем, тут upstream виноват -- но в
дистрибутиве это в любом случае лучше оторвать). Это создаёт 
жуткую задержку, а толку не видно.

Второй ужас в том, что нет разделения расширений по зависимости
от разных версий tcl, и по признаку "бинарное оно или pure tcl".
И _насколько_ оно зависит от версии -- tktable, например, можно
грузить в любой tcl/tk с 8.2 по 8.4, и ничего ему не будет --
а какой-нибудь Img  надо пересобирать.

(То есть, тут хорошо бы иметь каталоги /usr/lib/site-tcl/$version, по
которым раскладывать правильные pkgIndex'ы. Или класть pkgIndex'ы
в подкаталоги /usr/lib/tcl$version).
(Ну и /usr/local/lib/site-tcl завести, для полного щастья)

Ещё отрицательную роль играет догма "сошки должны быть в /usr/lib".
Вот у python'а сошки лежат чёрт знает где, и никто не возражает...
Ну ладно, пускай так надо -- потому что могут быть бинарники,
слинкованные с такой so-шкой. Но если собиратель пакета двигает
сошку в /usr/lib (а потом ещё и переименовывает в *so.$subversion),
то пропатчить pkgIndex он забывает, и package require эту сошку
уже не подцепит. И вот, даже package require Tk я из tclsh
сказать не могу... И package require expect тоже.

Ещё пригодился бы /usr/share/site-tcl, куда можно было бы 
ставить pure-tcl вещи типа tcllib и bwidget. И /etc/tkrc,
который читался бы из tk.tcl не только при интерактивном
запуске wish, а всегда.

Вот ещё есть пакет с blt -- у которого so-шки сделаны для всех трёх
тиклей, что есть в debian: (tcl,tk)8.[023]. Какую грузить -- он
выбирает автоматически через info version, и package require BLT
отработает в любом wish8.x нормально (но не в tclsh; см. выше, почему).
Замечательная идея, но при этом он build-depends от _всех_ tcl*-dev
и tk*-dev из дистрибутива, и дальше будет только хуже. Начиная с tcl8.4,
появляется ведь ещё вариант сборки tcl с тредами и без тредов --
то есть зоопарк раздваивается. Сколько тут новых граблей будет
для пакетостроителей -- и представить страшно.

В общем и целом, пришла мне мысль -- debian tcl policy надо рожать.
Чтобы понять, как _правильно_ разбираться с этими граблями, и к
авторам пакетов уже с конкретными предложениями лезть.

А потом я подумал -- может, кто-нибудь уже думал на ту же тему?
Неплохо было бы услышать... Решил спросить. Спрашиваю.

-- 
With Best Wishes, Anton Kovalenko /* http://kovalenko.webzone.ru */
#!/usr/bin/wish - best wish I have for you!


-- 
To UNSUBSCRIBE, email to debian-russian-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: