From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 17 Oct 2002 12:14:13 +0400 From: Mikhail Zabaluev To: devel@altlinux.ru Message-ID: <20021017081412.GB22143@mhz.mikhail.zabaluev.name> Mail-Followup-To: Mikhail Zabaluev , devel@altlinux.ru References: <20021016014557.GA29249@homestead.turbinal.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: <20021016014557.GA29249@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: --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello at, On Wed, Oct 16, 2002 at 05:45:57AM +0400, at@turbinal.org wrote: > > 2) я сделал перемещение некоторых модулей из perl в perl-base и > perl-devel. Это требуется для более эффективного разведения перловых > зависимостей в масштабах дистрибутива. (В частности, ExtUtils уехали в > perl-devel, а вместе с ними и CPAN.pm; это и другие решения будут > казаться правильными, если над ними подумать.) Ещё лучше обосновать эти решения публично. В оригинале, насколько я понимаю, perl-base был выделен в Mandrake для получения минимального набора, необходимого для инсталлятора (или drak'ов?). > 4) libperl.so* relocated to /usr/lib; у меня сложилось мнение, что > libperl.so* ничем не лучше и не хуже других *.so*. Сделано это следующим > образом: > > %make_build CCDLFLAGS="-rdynamic" > $PERL -pi -e "s/,-rpath,[^\s,'\"]+//g && s/\s*-Wl(?!,)//g" $RPM_BUILD_ROOT%archlib/Config.pm > mkdir -p $RPM_BUILD_ROOT%_libdir > mv $RPM_BUILD_ROOT%archlib/CORE/libperl.so.%sover $RPM_BUILD_ROOT%_libdir > ln -sf libperl.so.%sover $RPM_BUILD_ROOT%_libdir/libperl.so > > Последствия этого шага для других пакетов понятны мне не до конца, > однако проблем пока не замечено. Я при сборке 5.6.x не стал этого делать, чтобы: 1) не лезть супротив скриптов сборки вел. и уж. Perl; 2) не предоставлять лёгкого способа собрать что-либо с libperl.so, не пользуясь ExtUtils. Тем самым, неграмотные скрипты сборки оказываются на виду и переписываются грамотным образом. > 5) use of inc_version_list mechanism is finally deprecated. Default > values > > Configure variable Default value > $privlib $prefix/lib/perl5/$version > $archlib $prefix/lib/perl5/$version/$archname > > were changed to > > $privlib $prefix/lib/perl5 > $archlib $prefix/lib/perl5/$archname > > by mhz on Tue May 29 2001. Default values > > $sitelib $siteprefix/lib/perl5/site_perl/$version > $sitearch $siteprefix/lib/perl5/site_perl/$version/$archname > > are changed to > > $sitelib $siteprefix/lib/perl5/site_perl > $sitearch $siteprefix/lib/perl5/site_perl/$archname > > since now. > > Обоснование: создатели перла предусмотрели возможность иметь в системе > одновременно несколько версий перла, для каждого из которых существует > отдельное дерево библиотек. Дистрибутив такой возможности не > предусматривает; вернее, для этого есть /usr/local. В дистрибутиве есть > более надежные механизмы контроля версий и совместимости. Версии в sitelib/sitearch позволяли сохранять модули, собранные под старыми версиями perl; худшее, что могло случиться, это тихий "вывод из обращения" модулей, утративших совместимость. В любом случае такие модули придётся пересобирать, но без версий в sitelib/sitearch определить, под каким perl ABI был собран модуль, "невооружённым взглядом" невозможно без дополнительных усилий при сборке пакетов. > Есть претензии > и по существу механизма: возможна ситуация, когда старое дерево > библиотек совместимо с новым перлом лишь частично. Это мы имеем сейчас в > связи с изменениями в ABI. Очевидно, если хоть какие-то модули могли оказаться несовместимыми, всё дерево нужно объявлять несовместимым. > 6) я подумал и решил оставть названия каталогов > > /usr/lib/perl5/i386-linux > /usr/lib/perl5/site_perl/i386-linux > > а не i386-linux-thread-multi, как делают RH и MDK. На это есть две > причины: а) теперь все сборки будут с тредами; во всяком случае, нужны > будут очень веские причины, чтобы отказаться от сборки с тредами Например, стойкая несовместимость с тредами какой-либо библиотеки, которую использует какой-либо модуль. > б) > название каталога в любом случае условно и не всегда/не вполне > соответствует действительности. Оно соответствует некоторому выбору флагов при сборке, который стоит отличать от других возможных наборов флагов. Впрочем, насчёт сосуществования в системе threaded и не-threaded версий Perl я ничего не знаю. > 7) Замечены как минимум следующие модули, которые входят в оригинальный > перл (некоторые из них появились только в 5.8). Есть соображения как за, > так и против того, чтобы продолжать собирать их из/в виде отдельных > пакетов. С ними лучше пока ничего не делать. Я ещё помедитирую. В CPAN эти модули могут обновляться чаще, чем в дистрибутиве. Хотя, я не знаю тонкостей политики CPAN в отношении bundled модулей. > perl-Time-HiRes > perl-Storable > perl-MIME-Base64 > perl-CGI > perl-DB_File > perl-Digest-MD5 > perl-libnet > perl-Parse-RecDescent -- Stay tuned, MhZ JID: mookid@jabber.org ___________ Q: How many lawyers does it take to change a light bulb? A: One. Only it's his light bulb when he's done. --Pd0ReVV5GZGQvF3a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rnFUTKqCuNPJlLgRAtpsAKCcDRd3EtDxu8pm3+JhmcApPq1HEwCfeBNN 0qZSN1YPHlD6159S03UI4C0= =xlzR -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a--