From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: at@turbinal.org Date: Wed, 16 Oct 2002 05:45:57 +0400 To: devel@altlinux.ru Message-ID: <20021016014557.GA29249@homestead.turbinal.org> Mail-Followup-To: devel@altlinux.ru Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: [devel] 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: --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit В incoming заливается perl-5.8.0-alt0.3.nosrc.rpm. Следующий текст важнее некоторых других (моих). TOC Summary 0) update perl.req in your build environment 1) remove straight perl* dependencies 2) think of why your package wants something more than perl-base 3) soname changed 4) libperl.so* relocated 5) use of inc_version_list mechanism is finally deprecated 6) archlib name is i386-linux 7) clashes 8) charges Summary: начинается переход на perl 5.8. 0) обратите внимание на то, что пересборку любых пакетов, которые так или иначе требуют perl, нужно делать в среде с исправленным /usr/lib/rpm/perl.req; иначе будут сведены на нет все усилия по разведению зависимостей. 1) ПОЖАЛУЙСТА, уберите все прямые зависимости на perl* из ваших пакетов (либо предоставьте доказательства того, что /usr/lib/rpm/*req* отрабатывает некорректно). Особенно этим грешат пакеты php-*. php-gd: PreReq: php-common = %version-%release, perl нужно заменить на PreReq: php-common = %version-%release У меня сложилось ощущение, что многим из этих пакетов перл вообще не нужен, а зависимость появилась методом copy-paste. 2) я сделал перемещение некоторых модулей из perl в perl-base и perl-devel. Это требуется для более эффективного разведения перловых зависимостей в масштабах дистрибутива. (В частности, ExtUtils уехали в perl-devel, а вместе с ними и CPAN.pm; это и другие решения будут казаться правильными, если над ними подумать.) Расклад: $ ls -s1 perl-*5.8.0-alt0.1.i686.rpm 6703 perl-5.8.0-alt0.1.i686.rpm 1273 perl-base-5.8.0-alt0.1.i686.rpm 2162 perl-devel-5.8.0-alt0.1.i686.rpm 40 perl-suidperl-5.8.0-alt0.1.i686.rpm Приоритет пакетов (в смысле их необходимости в некоторых типичных/важных случаях): perl-base perl-devel Т.е. большинству пакетов с новым раскладом в конечном счете perl НЕ ДОЛЖЕН быть нужен. В Junior нужно включить только perl-base. Возможно, над этим придется дополнительно поработать. Кроме того, я проверил функциональную замкнутость perl-base и perl-devel относительно perl. Для этого я написал скрипт, который можно также использовать для анализа перловых зависимостей других пакетов. Скрипт прилагается (но он ни на что не претендует; желающие должны его доработать и обязательно об этом сообщить). В результате удалось предотвратить ряд ошибок, например таких: file /usr/lib/perl5/File/Spec/Unix.pm requires perl(Scalar/Util.pm) provided by perl-5.8.0-alt0.1 file /usr/lib/perl5/i386-linux-thread-multi/Data/Dumper.pm requires perl(B/Deparse.pm) provided by perl-devel-5.8.0-alt0.1 Благодаря формальной независимости perl-base от perl* удалось отключить AutoReq: yes, noperl. Теперь база RPM вырастет ещё раза в 2. :) Другой пример: $ perl depend.pl gnucash file /usr/bin/update-finance-quote requires perl(CPAN.pm) provided by perl-devel-5.8.0-alt0.1 Оказывается, что кроме учета частных средств, gnucash ещё умеет устанавливать на машине перловый софт! Хорошо это или плохо, я не знаю. Но для разведения зависимостей это killer, как и сам CPAN.pm. 3) soname changed: libperl.so.5.8; это сделано для явного указания бинарной несовместимости с perl 5.6. К сожалению, большинство perl-* пакетов сейчас собрано таким образом, что указать факт их бинарной несовместимости с новым перлом никак нельзя. Для того, чтобы избежать такой ситуации в будущем, в perl-* пакетах с бинарным кодом (*.so) я предлагаю явно указывать soname: PreReq: libperl.so.5.8 В пакетах без бинарного кода этого делать не нужно. В других пакетах, в которых бинарный код явно линкуется с libperl.so, этого делать также не нужно, т.к. эта зависимость должна быть обнаружена автоматически. 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 Последствия этого шага для других пакетов понятны мне не до конца, однако проблем пока не замечено. Вопрос: как правильно сделать non-lazy linking для /usr/bin/perl? 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. В дистрибутиве есть более надежные механизмы контроля версий и совместимости. Есть претензии и по существу механизма: возможна ситуация, когда старое дерево библиотек совместимо с новым перлом лишь частично. Это мы имеем сейчас в связи с изменениями в ABI. 6) я подумал и решил оставть названия каталогов /usr/lib/perl5/i386-linux /usr/lib/perl5/site_perl/i386-linux а не i386-linux-thread-multi, как делают RH и MDK. На это есть две причины: а) теперь все сборки будут с тредами; во всяком случае, нужны будут очень веские причины, чтобы отказаться от сборки с тредами б) название каталога в любом случае условно и не всегда/не вполне соответствует действительности. 7) Замечены как минимум следующие модули, которые входят в оригинальный перл (некоторые из них появились только в 5.8). Есть соображения как за, так и против того, чтобы продолжать собирать их из/в виде отдельных пакетов. С ними лучше пока ничего не делать. Я ещё помедитирую. perl-Time-HiRes perl-Storable perl-MIME-Base64 perl-CGI perl-DB_File perl-Digest-MD5 perl-libnet perl-Parse-RecDescent 8) Пересборку пакетов perl-libwww-perl perl-HTML-Parser я возьму на себя. --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="depend.pl" #!/usr/bin/perl # # check whether perl part of the package depends on perl-base only # use strict; my @packages = @ARGV; my $base = `rpm -q 'perl-base'`; chomp $base; foreach my $package (@packages) { $package = `rpm -q '$package'`; chomp $package; $_= `rpm -ql '$package' '$base' | sort | uniq`; my @files = split; my $n = @files; print "checking whether perl part of $package package ($n files) depends on $base only\n"; foreach my $file (@files) { my @req = `/usr/lib/rpm/perl.req '$file'`; @req = map { /perl\(.+?\)/ ? $& :() } @req; foreach my $req (@req) { $_ = `rpm -q --whatprovides '$req'`; my @prov = split; print "warning: $req is provided by @prov\n" if @prov > 1; print "file $file requires\n\t$req provided by @prov\n" unless grep { "@prov" =~ /\Q$_/ } ($base, $package); } } } --82I3+IH0IqGh5yIs--