Re: [devel] Re: perl-5.8.0-alt0.3 (important)

[at@turbinal.org]

On Thu, Oct 17, 2002 at 12:14:13PM +0400, Mikhail Zabaluev wrote:
> > 2) я сделал перемещение некоторых модулей из perl в perl-base и
> > perl-devel. Это требуется для более эффективного разведения перловых
> > зависимостей в масштабах дистрибутива. (В частности, ExtUtils уехали в
> > perl-devel, а вместе с ними и CPAN.pm; это и другие решения будут
> > казаться правильными, если над ними подумать.)
> 
> Ещё лучше обосновать эти решения публично.

Я проанализировал перловые зависимости в дистрибутиве (вернее, в том,
что установлено у меня на машине; но это достаточно типичная установка).
С ними оказалось не всё гладко. Чтобы это понять, нужно выполнить
команду

$ rpm -e --test perl
или
# apt-get -s remove perl

(почему apt-get не хочет ничего показывать без рута, я не понимаю).

Слишком много пакетов и слишком дико хотят перла. Без перла дистрибутив
невозможен ни в какой форме. Вместе с тем, не всё было гладко и с самим
перлом, судя хотя бы по тому, что он собирался с "AutoReq: yes, noperl".
Попытка втиснуть новый перл в старый спек без существенных изменений
показала, что число проблем только увеличивается.

Все пакеты, которые отзываются на rpm -e --test perl в виде 'perl',
попросту не хотят использовать возможности, которые предоставляет (или
не предоставляет) пакет rpm-build.

Все пакеты, которые отзываются на rpm -e --test perl в виде 'perl >=',
содержат эту зависимость из-за некорректной работы пакета rpm-build.

Ко всем пакетам, которые отзываются на rpm -e --test perl в виде
'perl(XXX.pm)', я применял следующие критерии:

1) субъективное ощущение того, насколько важным является пакет
2) функциональность пакета
3) чего он хочет от перла и почему он это хочет (gnucash меня взбесил)
4) число пакетов, которые хотят того же самого
...
N) приведет ли какое-нибудь перераспределение в перловых пакетах к более
эффективному распределение зависимостей в дистрибутиве.

Что касается ExtUtils, то они используются для компиляции и установки
перлового софта. MakeMaker зовёт xsubpp, что суть ранняя стадия
подготовки исходников. Затем MakeMaker будет звать gcc, которому, чтобы
родить на свет из этих исходников хоть какой-нибудь бинарь, потребуются
хедеры. Все эти зависимости нельзя обнаружить формально, но они реально
существуют. Поэтому ExtUtils прямая дорога в perl-devel. Я даже считаю,
что включение их в perl было изначально ошибочным.

Что касается CPAN.pm -- то это killer по части зависимостей. Он хочет
всего сразу, включая ExtUtils, perl-libnet и perl-libwww-perl. Однако
главное его назначение -- вовремя задействовать механизм, описанный в
предыдущем параграфе. С большими потерями удалось вытеснить его в
perl-devel (пришлось также внести несколько модулей в perl-base, чтобы
perl-devel не зависел от perl; но позже выяснилось, что внесение этих
модулей в perl-base отвязывают от perl ещё несколько пакетов).

Если оставить ExtUtils или CPAN в пакете perl, то появится явная или
неявная зависимость perl от perl-devel, от которой всё разбиение
потеряет смысл.

Самая большая потеря -- внесение vmsish.pm в perl-base, т.к. он
формально требуется для perl-DBI, который в свою очередь окольными
путями требуется для MySQL-server.

> В оригинале, насколько я понимаю, perl-base был выделен
> в Mandrake для получения минимального набора, необходимого
> для инсталлятора (или drak'ов?).

Вместе с тем, нет никакого смысла в такой минимизации, при которой в
любых важных/типичных инсталляциях perl-base оказывается недостаточно, и
неминуемо приходится тянуть за собой perl. Сейчас это именно так. 
Junior -- это как раз один из таких важных случаев. Само разбиение в
таком случае теряет смысл, и получается, что лучше честно собирать perl
одним пакетом, как RH.

Я особо хочу подчеркнуть, что размер пакета perl-base вырос НЕ ТОЛЬКО
из-за моей инициативы по перемещению в него дополнительных модулей. Есть
ещё две причины:

1) сам перл и всё в нём изрядно потолстело; это видно из размера
тарболла; на самом деле, от перераспределения модулей размер perl-base
увеличился примерно на 20-30%, а не на 100%, как это может показаться на
первый взгляд; perl-base остается эффективно маленьким относительно perl
и perl-devel.

2) сильно изменились внутренние зависимости в перловых модулях; в целом,
плотность зависимостей увеличилась.

> Версии в sitelib/sitearch позволяли сохранять модули,
> собранные под старыми версиями perl; худшее, что могло случиться,

Отсутствие версий в sitelib/sitearch позволяет сохранять модули,
собранные под старыми версиями perl.

> это тихий "вывод из обращения" модулей, утративших совместимость.

Если этот модуль кто-то использует, то тихого вывода из обращения не
получится. То есть, в этом, конечно, есть смысл, но это противоречит
идеалам создания дистрибутива с сильным контролем зависимостей.

> > Есть претензии
> > и по существу механизма: возможна ситуация, когда старое дерево
> > библиотек совместимо с новым перлом лишь частично. Это мы имеем сейчас в
> > связи с изменениями в ABI.
> 
> Очевидно, если хоть какие-то модули могли оказаться несовместимыми,
> всё дерево нужно объявлять несовместимым.

Это явная ошибка в дизайне inc_version_list (нужно было сделать две
таких директивы, одну для privlib, другую для archlib). Ошибка в
дизайне -- это ещё одна причина, по которой я счел возможным отказаться
от использования inc_version_list. Нам не нужны ошибочные решения. :)

> > причины: а) теперь все сборки будут с тредами; во всяком случае, нужны
> > будут очень веские причины, чтобы отказаться от сборки с тредами
> 
> Например, стойкая несовместимость с тредами какой-либо библиотеки,
> которую использует какой-либо модуль.

Да, это есть весьма веская причина.
Вместе с тем, это есть намек на пример, которого нет.

Страшно другое: для других пакетов сборка с тредами может быть бинарно
несовместима со сборкой без тредов. Так это или нет, я не знаю, и пока
даже не знаю, как узнать. Вы не в курсе?

> > название каталога в любом случае условно и не всегда/не вполне
> > соответствует действительности.
> 
> Оно соответствует некоторому выбору флагов при сборке, который стоит
> отличать от других возможных наборов флагов.

Это имеет смысл, но этим нельзя всерьёз увлекаться в дистрибутиве с
сильным контролем зависимостей.

> В CPAN эти модули могут обновляться чаще, чем в дистрибутиве.

Однако бундель перед релизом тестируется, а CPAN -- это просто
лавочка по агрегации частных инициатив.

> Хотя, я не знаю тонкостей политики CPAN в отношении
> bundled модулей.