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.