From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: at@turbinal.org Date: Sat, 19 Oct 2002 03:42:41 +0400 To: devel@altlinux.ru Subject: Re: [devel] Re: perl-5.8.0-alt0.3 (important) Message-ID: <20021018234241.GA5988@homestead.turbinal.org> Mail-Followup-To: devel@altlinux.ru References: <20021016014557.GA29249@homestead.turbinal.org> <20021017081412.GB22143@mhz.mikhail.zabaluev.name> <20021018014056.GA4494@homestead.turbinal.org> <20021018222612.GA2153@mhz.mikhail.zabaluev.name> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20021018222612.GA2153@mhz.mikhail.zabaluev.name> Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: 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.