[devel] perl-5.8.0-alt0.3 (important)

* [devel] perl-5.8.0-alt0.3 (important)
@ 2002-10-16  1:45 at
  2002-10-16  4:44 ` at
                   ` (3 more replies)
  0 siblings, 4 replies; 31+ messages in thread
From: at @ 2002-10-16  1:45 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 6190 bytes --]

В 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
я возьму на себя.

[-- Attachment #2: depend.pl --]
[-- Type: text/plain, Size: 830 bytes --]

#!/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);
		}
	}
}

^ permalink raw reply	[flat|nested] 31+ messages in thread