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

[Mikhail Zabaluev <mhz@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 7284 bytes --]

Hello at,

On Fri, Oct 18, 2002 at 05:40:56AM +0400, at@turbinal.org wrote:
>
> 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, от которой всё разбиение
> потеряет смысл.

CPAN явно не место в perl-devel.
Hint: perl-CPAN?

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

Я бы вообще не задавался идеей ставить только perl-base
в какой бы то ни было инсталляции. Наоборот, лучше было
бы отпилить от пакета perl те модули, которые требуют
нетривиального, типа DB*_File и GDBM_File, и объединить
его c perl-base. Пользователям Junior может стать
обидно, что perl у них есть, но умеет явно меньше,
чем то, что про него пишут в книжках.
Если уж есть нужда в настолько минималистичной инсталляции,
то perl там вообще лишний.

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

Есть гарантия, что это не приведёт к крэшам при использовании
несовместимых модулей? Соответствие ABI проверяется при
динамической загрузке?

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

Противоречит, но кому охота прописывать зависимость от версии
perl во все пакеты?
Или жёстко (полу-)автоматически привязывать пакеты к версии
perl и при смене этой версии всё пересобирать?

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

Это не ошибка, а недоработка, и с задачей, для которой фича была
введена, она справляется хотя бы частично.

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

Нет, но скорее всего, несовместима.

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

Не понял, при чём здесь контроль зависимостей? И что значит "сильный"?

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

Ну как, без make test туда вроде бы тоже не пускают,
а в bundle выполняется тот же make test тех же модулей.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
I love treason but hate a traitor.
		-- Gaius Julius Caesar

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]