From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 19 Oct 2002 13:38:46 +0400 From: Mikhail Zabaluev To: devel@altlinux.ru Message-ID: <20021019093846.GA54@mhz.mikhail.zabaluev.name> Mail-Followup-To: Mikhail Zabaluev , 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> <20021018234241.GA5988@homestead.turbinal.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <20021018234241.GA5988@homestead.turbinal.org> User-Agent: Mutt/1.4i Subject: [devel] Re: perl-5.8.0-alt0.3 (important) 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: --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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. --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9sSgmTKqCuNPJlLgRAoDYAJ44r8+TZLsOgTenKtfIpED6cTbWAwCgx/PS SUS53KAc6Eq8gd4Qn5+whlM= =8A/Q -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn--