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

[at@turbinal.org]

On Sat, Oct 19, 2002 at 02:26:12AM +0400, Mikhail Zabaluev wrote:
> CPAN явно не место в perl-devel.
> Hint: perl-CPAN?

Не знаю. Я хотел бы избежать дальнейшего дробления основных перловых
пакетов. По плотности зависимостей -- никуда кроме как в perl-devel его
сейчас деть нельзя, да и perl-devel из-за него начинает хотеть libnet,
libwww и т.п.

Да, наверное, стоит сделать perl-CPAN.

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

Сюрприз, сюрприз! Я так и сделал. Вот что у меня на эту тему в спеке.

%files base
# perl-base modules
	%privlib/AnyDBM_File.pm
# dbm stuff: include only one in perl-base to satisfy AnyDBM_File;
# proirities according to AnyDBM_File.pm
%if_with ndbm
	%archlib/NDBM_File.pm
	%autolib/NDBM_File
%else
%if_with db
	%archlib/DB_File.pm
	%autolib/DB_File
%else
%if_with gdbm
	%archlib/GDBM_File.pm
	%autolib/GDBM_File
%else
%if_with sdbm
	%archlib/SDBM_File.pm
	%autolib/SDBM_File
	%autolib/sdbm
%endif
%endif
%endif
%endif

%files
# dbm stuff
%if_with ndbm
%if_with db
	%archlib/DB_File.pm
	%autolib/DB_File
%endif
%if_with gdbm
	%archlib/GDBM_File.pm
	%autolib/GDBM_File
%endif
%if_with sdbm
	%archlib/SDBM_File.pm
	%autolib/SDBM_File
	%autolib/sdbm
%endif
%else
%if_with db
%if_with gdbm
	%archlib/GDBM_File.pm
	%autolib/GDBM_File
%endif
%if_with sdbm
	%archlib/SDBM_File.pm
	%autolib/SDBM_File
	%autolib/sdbm
%endif
%else
%if_with gdbm
%if_with sdbm
	%archlib/SDBM_File.pm
	%autolib/SDBM_File
	%autolib/sdbm
%endif
%endif
%endif
%endif

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

Нет. Полную гарантию может дать только...

Соответствие API/ABI должен проверять дистрибутив, и он может делать это
лучше, чем inc_version_list.

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

Нужно жестко зашивать версию ABI в пакеты с бинарным кодом, и при смене
ABI у перла apt должет приказать им долго жить. :) Версию ABI легче
всего идентифицировать по libperl soname.

PreReq: libperl.so.5.8

При этом мы получаем мягкий вариант контроля бинарной совместимости как
минимум для всех perl-5.8.x, т.е. на достаточно долгое время. Если
perl-5.10 будет бинарно совместим с perl-5.8, то:

%package base
Provides: libperl.so.5.8

%install
ln -sf libperl.so.5.10 libperl.so.5.8

При этом все остальные перловые пакеты можно будет не пересобирать, а
при пересборке можно оставлять старый soname. Тогда будет возможность
обновить этот пакет без обновления самого перла. К сожалению, этого не
получится сделать там, где бинарный код явно слинкуется с
libperl.so.5.10.

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

Если вы предлагаете оставить inc_version_list, скажите об этом явно.

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

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

Как лучше сделать?

1) виртуальные provides. Так сделано в RH:
Provides: perl(:WITH_ITHREADS)
Provides: perl(:WITH_THREADS)

2) дальнейшее усложнение soname:
libperl-ithreads.so.5.8
libperl-nothreads.so.5.8

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

3) оставить пока libperl.so.5.8;
при откате назвать libperl-nothreads.so.5.8.
Так и сделаем.

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

В целом же, я думаю, что мы хорошо понимаем друг друга.

В целостном состоянии дистрибутива на основе apt/rpm невозможно
одновременное существование бинарно несовместимых пакетов. По этой
причине нет смысла учитывать флаги сборки в названии archlib.