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

[Mikhail Zabaluev <mhz@altlinux.org>]

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

Hello at,

On Sat, Oct 19, 2002 at 03:42:41AM +0400, at@turbinal.org wrote:
>
> 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 совсем,
проставив его собственную версию. Тогда его можно будет
и брать с зеркал 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

Nooooooo
Их просто нужно вынести в отдельные пакеты по аналогии с CPAN.
Дробление здесь оправдано наличием зависимостей на db и
gdbm. SDBM_File можно оставить в главном пакете.
То, что AnyDBM_File чего-то там не хватает, это не проблема.
У нас же стоял при сборке AutoReq: yes, noperl :)

> > Есть гарантия, что это не приведёт к крэшам при использовании
> > несовместимых модулей? Соответствие 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.

Есть одна проблема: последний раз, когда я проверял, бинарные
модули не линковались с libperl.so. Они и не должны,
поскольку это их динамически загружает DynaLoader в
уже готовое окружение.
То есть, автоматика нам эту зависимость не найдёт.
Прописывать руками зависимость таких пакетов на libperl.so.X.Y
можно, но это мартышкин труд.

> > Это не ошибка, а недоработка, и с задачей, для которой фича была
> > введена, она справляется хотя бы частично.
> 
> Если вы предлагаете оставить inc_version_list, скажите об этом явно.

Если других надёжных способов нет, почему бы не оставить
inc_version_list как его разумеют авторы perl? В конце
концов, все эти радикальные отличия вводят в смущение
пользователей, которые привыкли к тому, как оно
обычно устроено.
Впрочем, одну выгоду я осознал: noarch-пакеты не нужно пересобирать
при смене версии perl, даже если они вышли бы из 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.
> Так и сделаем.

Угу. Всё-таки неприспособленные к threads библиотеки -- это
анахронизм, который надо изживать.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Slang is language that takes off its coat, spits on its hands, and goes to work.

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