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

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

[at]

[-- 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);
		}
	}
}

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

[at]

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

On Wed, Oct 16, 2002 at 05:45:57AM +0400, at@turbinal.org wrote:
> 
> В incoming заливается perl-5.8.0-alt0.3.nosrc.rpm.

Залилось. :)

> относительно perl. Для этого я написал скрипт, который можно также
> использовать для анализа перловых зависимостей других пакетов. Скрипт
> прилагается (но он ни на что не претендует; желающие должны его
> доработать и обязательно об этом сообщить). В результате удалось

Доработал.


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

#!/usr/bin/perl
#
# check whether perl part of the package depends on perl-base only
#

use strict;
sub whatsays($) {
	my $command = shift;
	local $_ = `$command`;
	$? and print qq(warning: $command\n\texecuted with $? status\n);
	my @parts = split;
	return wantarray ? @parts : $parts[0];
}
my %cache;
my $n_call = 0;
sub whatprovides(@) {
	my $prov = shift;
	if ($cache{$prov}) {
		$n_call++;
	} else {
		my @pkgs = whatsays qq(rpm -q --whatprovides '$prov');
		$cache{$prov} = \@pkgs;
		print "warning: $prov is provided by " . join(' AND ' => @pkgs) . "\n"
			if @pkgs > 1;
	}
	return @{$cache{$prov}};
}
my @packages = @ARGV;
my $base = whatsays qq(rpm -q 'perl-base');
foreach my $package (@packages) {
	$package = whatsays qq(rpm -q '$package');
	my @files = whatsays qq(rpm -ql '$package' '$base' | sort | uniq);
	my $n = @files;
	print "checking whether perl part of $package package ($n files)\n\tdepends on $base only\n";
	foreach my $file (@files) {
		my @req = map { /perl\(.+?\)/ ? $& :() } whatsays qq(/usr/lib/rpm/perl.req '$file');
		foreach my $req (@req) {
			my @prov = whatprovides $req;
			print "file $file requires\n\t$req provided by @prov\n" 
				unless grep { "@prov" =~ /\Q$_/ } ($base, $package);
		}
	}
}
print "whatprovides: " . keys(%cache) . " entries cached ($n_call fork+exec calls saved)\n";

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

[Dmitry V. Levin]

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

On Wed, Oct 16, 2002 at 08:44:30AM +0400, at@turbinal.org wrote:
> > относительно perl. Для этого я написал скрипт, который можно также
> > использовать для анализа перловых зависимостей других пакетов. Скрипт
> > прилагается (но он ни на что не претендует; желающие должны его
> > доработать и обязательно об этом сообщить). В результате удалось
> 
> Доработал.

Ещё лучше иметь версию, которая вместо
rpm -q '$package'
будет делать
rpm -qp '$package'

С помощью такой версии можно будет проверять свежесобранные пакеты.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[at]

On Wed, Oct 16, 2002 at 12:54:17PM +0400, Dmitry V. Levin wrote:
> Ещё лучше иметь версию, которая вместо
> rpm -q '$package'
> будет делать
> rpm -qp '$package'
> 
> С помощью такой версии можно будет проверять свежесобранные пакеты.

Проблема в том, что --whatprovides работает только для установленных
пакетов. Т.е. при -qp буду неверно обработаны внутренние зависимости в
пакете. Это опять наводит на мысль о том, что RPM должен удалять
разрешенные зависимости в пределах одного пакета. Конечно, можно удалять
такие зависимости в самом скрипте.

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

[Dmitry V. Levin]

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

On Wed, Oct 16, 2002 at 06:47:22PM +0400, at@turbinal.org wrote:
> > Ещё лучше иметь версию, которая вместо
> > rpm -q '$package'
> > будет делать
> > rpm -qp '$package'
> > 
> > С помощью такой версии можно будет проверять свежесобранные пакеты.
> 
> Проблема в том, что --whatprovides работает только для установленных
> пакетов. Т.е. при -qp буду неверно обработаны внутренние зависимости в
> пакете. Это опять наводит на мысль о том, что RPM должен удалять
> разрешенные зависимости в пределах одного пакета. Конечно, можно удалять
> такие зависимости в самом скрипте.

Ok, тогда волшебная директива
rpmi --dbpath /path/to/custom/rpmdb --define '__dbi_htconfig hash nofsync %{__dbi_other} %{__dbi_perms}' -ihv --justdb --nodeps --noorder --noscripts --notriggers --ignoresize --force *.rpm решит проблему.

При условии, что depend.pl'у можно будет переопределить rpm на свой
скрипт, который, в свою очередь, сделает "rpmquery --dbpath /path/to/custom/rpmdb".


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Alexander Bokovoy]

On Wed, Oct 16, 2002 at 05:45:57AM +0400, at@turbinal.org wrote:
> 1) ПОЖАЛУЙСТА, уберите все прямые зависимости на perl* из ваших пакетов
> (либо предоставьте доказательства того, что /usr/lib/rpm/*req*
> отрабатывает некорректно). Особенно этим грешат пакеты php-*. php-gd:
> 
> PreReq: php-common = %version-%release, perl
> 
> нужно заменить на
> 
> PreReq: php-common = %version-%release
> 
> У меня сложилось ощущение, что многим из этих пакетов перл вообще не
> нужен, а зависимость появилась методом copy-paste.
Нет, perl в них нужен на стадии установки. Точнее, нужен perl-base. Хотя,
с введением нового функционала в subst, необходимость в завязке на
perl-base отпала. Как только получу обновленное локальное зеркало Сизифа,
устрою пересборку PHP в BTE.

-- 
/ Alexander Bokovoy
---
Etiquette is for those with no breeding; fashion for those with no taste.

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

[Stanislav Ievlev]

On Wed, Oct 16, 2002 at 11:39:18AM +0300, Alexander Bokovoy wrote:
> On Wed, Oct 16, 2002 at 05:45:57AM +0400, at@turbinal.org wrote:
> > 1) ПОЖАЛУЙСТА, уберите все прямые зависимости на perl* из ваших пакетов
> > (либо предоставьте доказательства того, что /usr/lib/rpm/*req*
> > отрабатывает некорректно). Особенно этим грешат пакеты php-*. php-gd:
> > 
> > PreReq: php-common = %version-%release, perl
> > 
> > нужно заменить на
> > 
> > PreReq: php-common = %version-%release
> > 
> > У меня сложилось ощущение, что многим из этих пакетов перл вообще не
> > нужен, а зависимость появилась методом copy-paste.
> Нет, perl в них нужен на стадии установки. Точнее, нужен perl-base. Хотя,
> с введением нового функционала в subst, необходимость в завязке на
> perl-base отпала. Как только получу обновленное локальное зеркало Сизифа,
> устрою пересборку PHP в BTE.
Очень было бы здорово устроить это на текущей неделе. Тогда следующую
мы сможем посвятить perl.
> 
> -- 
> / Alexander Bokovoy
> ---
> Etiquette is for those with no breeding; fashion for those with no taste.
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

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

[Dmitry V. Levin]

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

On Wed, Oct 16, 2002 at 05:45:57AM +0400, at@turbinal.org wrote:
> 3) soname changed: libperl.so.5.8; это сделано для явного указания
> бинарной несовместимости с perl 5.6. К сожалению, большинство perl-*
> пакетов сейчас собрано таким образом, что указать факт их бинарной
> несовместимости с новым перлом никак нельзя. Для того, чтобы избежать
> такой ситуации в будущем, в perl-* пакетах с бинарным кодом (*.so) я
> предлагаю явно указывать soname:
> 
> PreReq: libperl.so.5.8
> 
> В пакетах без бинарного кода этого делать не нужно. В других пакетах, в
> которых бинарный код явно линкуется с libperl.so, этого делать также не
> нужно, т.к. эта зависимость должна быть обнаружена автоматически.

А почему многие перловые пакеты, содержащие .so-файлы в недрах
/usr/lib/perl5/, не линкуют их с -lperl? Это вообще правильно?


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Anton V. Boyarshinov]

On Wed, 16 Oct 2002 12:50:02 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> А почему многие перловые пакеты, содержащие .so-файлы в недрах
> /usr/lib/perl5/, не линкуют их с -lperl? Это вообще правильно?
Насколько я понимаю -- правильно. Поскольку при их исползовании
не они прилинковывают к себе perl, а наоборот.

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 12:52pm  up 1 day,  1:50,  2 users,  load average: 0.27, 0.08,
0.02

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

[at]

On Wed, Oct 16, 2002 at 12:56:53PM +0400, Anton V. Boyarshinov wrote:
> On Wed, 16 Oct 2002 12:50:02 +0400
> "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> 
> > А почему многие перловые пакеты, содержащие .so-файлы в недрах
> > /usr/lib/perl5/, не линкуют их с -lperl? Это вообще правильно?
> Насколько я понимаю -- правильно. Поскольку при их исползовании
> не они прилинковывают к себе perl, а наоборот.

Да. Это не совсем обычные библиотеки, т.к. они динамически
загружаются/линкуются перлом с помощью DynaLoader(3). Кроме того, он
умеет их выгружать. Более того, можно предусмотреть различные варианты
поведения перла при ошибках в линковке. К сожалению, перл не может
определить, какие из этих ошибок являются следствием бинарной
несовместимости. :)

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

[Mikhail Zabaluev]

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

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[at]

On Thu, Oct 17, 2002 at 12:14:13PM +0400, Mikhail Zabaluev wrote:
> > 2) я сделал перемещение некоторых модулей из perl в perl-base и
> > perl-devel. Это требуется для более эффективного разведения перловых
> > зависимостей в масштабах дистрибутива. (В частности, ExtUtils уехали в
> > perl-devel, а вместе с ними и CPAN.pm; это и другие решения будут
> > казаться правильными, если над ними подумать.)
> 
> Ещё лучше обосновать эти решения публично.

Я проанализировал перловые зависимости в дистрибутиве (вернее, в том,
что установлено у меня на машине; но это достаточно типичная установка).
С ними оказалось не всё гладко. Чтобы это понять, нужно выполнить
команду

$ rpm -e --test perl
или
# apt-get -s remove perl

(почему apt-get не хочет ничего показывать без рута, я не понимаю).

Слишком много пакетов и слишком дико хотят перла. Без перла дистрибутив
невозможен ни в какой форме. Вместе с тем, не всё было гладко и с самим
перлом, судя хотя бы по тому, что он собирался с "AutoReq: yes, noperl".
Попытка втиснуть новый перл в старый спек без существенных изменений
показала, что число проблем только увеличивается.

Все пакеты, которые отзываются на rpm -e --test perl в виде 'perl',
попросту не хотят использовать возможности, которые предоставляет (или
не предоставляет) пакет rpm-build.

Все пакеты, которые отзываются на rpm -e --test perl в виде 'perl >=',
содержат эту зависимость из-за некорректной работы пакета rpm-build.

Ко всем пакетам, которые отзываются на rpm -e --test perl в виде
'perl(XXX.pm)', я применял следующие критерии:

1) субъективное ощущение того, насколько важным является пакет
2) функциональность пакета
3) чего он хочет от перла и почему он это хочет (gnucash меня взбесил)
4) число пакетов, которые хотят того же самого
...
N) приведет ли какое-нибудь перераспределение в перловых пакетах к более
эффективному распределение зависимостей в дистрибутиве.

Что касается ExtUtils, то они используются для компиляции и установки
перлового софта. MakeMaker зовёт xsubpp, что суть ранняя стадия
подготовки исходников. Затем MakeMaker будет звать gcc, которому, чтобы
родить на свет из этих исходников хоть какой-нибудь бинарь, потребуются
хедеры. Все эти зависимости нельзя обнаружить формально, но они реально
существуют. Поэтому ExtUtils прямая дорога в perl-devel. Я даже считаю,
что включение их в perl было изначально ошибочным.

Что касается CPAN.pm -- то это killer по части зависимостей. Он хочет
всего сразу, включая ExtUtils, perl-libnet и perl-libwww-perl. Однако
главное его назначение -- вовремя задействовать механизм, описанный в
предыдущем параграфе. С большими потерями удалось вытеснить его в
perl-devel (пришлось также внести несколько модулей в perl-base, чтобы
perl-devel не зависел от perl; но позже выяснилось, что внесение этих
модулей в perl-base отвязывают от perl ещё несколько пакетов).

Если оставить ExtUtils или CPAN в пакете perl, то появится явная или
неявная зависимость perl от perl-devel, от которой всё разбиение
потеряет смысл.

Самая большая потеря -- внесение vmsish.pm в perl-base, т.к. он
формально требуется для perl-DBI, который в свою очередь окольными
путями требуется для MySQL-server.

> В оригинале, насколько я понимаю, perl-base был выделен
> в Mandrake для получения минимального набора, необходимого
> для инсталлятора (или drak'ов?).

Вместе с тем, нет никакого смысла в такой минимизации, при которой в
любых важных/типичных инсталляциях perl-base оказывается недостаточно, и
неминуемо приходится тянуть за собой perl. Сейчас это именно так. 
Junior -- это как раз один из таких важных случаев. Само разбиение в
таком случае теряет смысл, и получается, что лучше честно собирать perl
одним пакетом, как RH.

Я особо хочу подчеркнуть, что размер пакета perl-base вырос НЕ ТОЛЬКО
из-за моей инициативы по перемещению в него дополнительных модулей. Есть
ещё две причины:

1) сам перл и всё в нём изрядно потолстело; это видно из размера
тарболла; на самом деле, от перераспределения модулей размер perl-base
увеличился примерно на 20-30%, а не на 100%, как это может показаться на
первый взгляд; perl-base остается эффективно маленьким относительно perl
и perl-devel.

2) сильно изменились внутренние зависимости в перловых модулях; в целом,
плотность зависимостей увеличилась.

> Версии в sitelib/sitearch позволяли сохранять модули,
> собранные под старыми версиями perl; худшее, что могло случиться,

Отсутствие версий в sitelib/sitearch позволяет сохранять модули,
собранные под старыми версиями perl.

> это тихий "вывод из обращения" модулей, утративших совместимость.

Если этот модуль кто-то использует, то тихого вывода из обращения не
получится. То есть, в этом, конечно, есть смысл, но это противоречит
идеалам создания дистрибутива с сильным контролем зависимостей.

> > Есть претензии
> > и по существу механизма: возможна ситуация, когда старое дерево
> > библиотек совместимо с новым перлом лишь частично. Это мы имеем сейчас в
> > связи с изменениями в ABI.
> 
> Очевидно, если хоть какие-то модули могли оказаться несовместимыми,
> всё дерево нужно объявлять несовместимым.

Это явная ошибка в дизайне inc_version_list (нужно было сделать две
таких директивы, одну для privlib, другую для archlib). Ошибка в
дизайне -- это ещё одна причина, по которой я счел возможным отказаться
от использования inc_version_list. Нам не нужны ошибочные решения. :)

> > причины: а) теперь все сборки будут с тредами; во всяком случае, нужны
> > будут очень веские причины, чтобы отказаться от сборки с тредами
> 
> Например, стойкая несовместимость с тредами какой-либо библиотеки,
> которую использует какой-либо модуль.

Да, это есть весьма веская причина.
Вместе с тем, это есть намек на пример, которого нет.

Страшно другое: для других пакетов сборка с тредами может быть бинарно
несовместима со сборкой без тредов. Так это или нет, я не знаю, и пока
даже не знаю, как узнать. Вы не в курсе?

> > название каталога в любом случае условно и не всегда/не вполне
> > соответствует действительности.
> 
> Оно соответствует некоторому выбору флагов при сборке, который стоит
> отличать от других возможных наборов флагов.

Это имеет смысл, но этим нельзя всерьёз увлекаться в дистрибутиве с
сильным контролем зависимостей.

> В CPAN эти модули могут обновляться чаще, чем в дистрибутиве.

Однако бундель перед релизом тестируется, а CPAN -- это просто
лавочка по агрегации частных инициатив.

> Хотя, я не знаю тонкостей политики CPAN в отношении
> bundled модулей.

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

[Mikhail Zabaluev]

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

Hello at,

On Fri, Oct 18, 2002 at 05:40:56AM +0400, at@turbinal.org wrote:
>
> On Thu, Oct 17, 2002 at 12:14:13PM +0400, Mikhail Zabaluev wrote:
> > > 2) я сделал перемещение некоторых модулей из perl в perl-base и
> > > perl-devel. Это требуется для более эффективного разведения перловых
> > > зависимостей в масштабах дистрибутива. (В частности, ExtUtils уехали в
> > > perl-devel, а вместе с ними и CPAN.pm; это и другие решения будут
> > > казаться правильными, если над ними подумать.)
> > 
> > Ещё лучше обосновать эти решения публично.
> 
> Я проанализировал перловые зависимости в дистрибутиве (вернее, в том,
> что установлено у меня на машине; но это достаточно типичная установка).
> С ними оказалось не всё гладко. Чтобы это понять, нужно выполнить
> команду
> 
> $ rpm -e --test perl
> или
> # apt-get -s remove perl
> 
> (почему apt-get не хочет ничего показывать без рута, я не понимаю).
> 
> Слишком много пакетов и слишком дико хотят перла. Без перла дистрибутив
> невозможен ни в какой форме. Вместе с тем, не всё было гладко и с самим
> перлом, судя хотя бы по тому, что он собирался с "AutoReq: yes, noperl".
>
> Попытка втиснуть новый перл в старый спек без существенных изменений
> показала, что число проблем только увеличивается.
> 
> Все пакеты, которые отзываются на rpm -e --test perl в виде 'perl',
> попросту не хотят использовать возможности, которые предоставляет (или
> не предоставляет) пакет rpm-build.
> 
> Все пакеты, которые отзываются на rpm -e --test perl в виде 'perl >=',
> содержат эту зависимость из-за некорректной работы пакета rpm-build.
> 
> Ко всем пакетам, которые отзываются на rpm -e --test perl в виде
> 'perl(XXX.pm)', я применял следующие критерии:
> 
> 1) субъективное ощущение того, насколько важным является пакет
> 2) функциональность пакета
> 3) чего он хочет от перла и почему он это хочет (gnucash меня взбесил)
> 4) число пакетов, которые хотят того же самого
> ...
> N) приведет ли какое-нибудь перераспределение в перловых пакетах к более
> эффективному распределение зависимостей в дистрибутиве.
> 
> Что касается ExtUtils, то они используются для компиляции и установки
> перлового софта. MakeMaker зовёт xsubpp, что суть ранняя стадия
> подготовки исходников. Затем MakeMaker будет звать gcc, которому, чтобы
> родить на свет из этих исходников хоть какой-нибудь бинарь, потребуются
> хедеры. Все эти зависимости нельзя обнаружить формально, но они реально
> существуют. Поэтому ExtUtils прямая дорога в perl-devel. Я даже считаю,
> что включение их в perl было изначально ошибочным.
> 
> Что касается CPAN.pm -- то это killer по части зависимостей. Он хочет
> всего сразу, включая ExtUtils, perl-libnet и perl-libwww-perl. Однако
> главное его назначение -- вовремя задействовать механизм, описанный в
> предыдущем параграфе. С большими потерями удалось вытеснить его в
> perl-devel (пришлось также внести несколько модулей в perl-base, чтобы
> perl-devel не зависел от perl; но позже выяснилось, что внесение этих
> модулей в perl-base отвязывают от perl ещё несколько пакетов).
> 
> Если оставить ExtUtils или CPAN в пакете perl, то появится явная или
> неявная зависимость perl от perl-devel, от которой всё разбиение
> потеряет смысл.

CPAN явно не место в perl-devel.
Hint: perl-CPAN?

> > В оригинале, насколько я понимаю, perl-base был выделен
> > в Mandrake для получения минимального набора, необходимого
> > для инсталлятора (или drak'ов?).
> 
> Вместе с тем, нет никакого смысла в такой минимизации, при которой в
> любых важных/типичных инсталляциях perl-base оказывается
> недостаточно, и
> неминуемо приходится тянуть за собой perl. Сейчас это именно так. 
> Junior -- это как раз один из таких важных случаев. Само разбиение в
> таком случае теряет смысл, и получается, что лучше честно собирать perl
> одним пакетом, как RH.

Я бы вообще не задавался идеей ставить только perl-base
в какой бы то ни было инсталляции. Наоборот, лучше было
бы отпилить от пакета perl те модули, которые требуют
нетривиального, типа DB*_File и GDBM_File, и объединить
его c perl-base. Пользователям Junior может стать
обидно, что perl у них есть, но умеет явно меньше,
чем то, что про него пишут в книжках.
Если уж есть нужда в настолько минималистичной инсталляции,
то perl там вообще лишний.

> > Версии в sitelib/sitearch позволяли сохранять модули,
> > собранные под старыми версиями perl; худшее, что могло случиться,
> 
> Отсутствие версий в sitelib/sitearch позволяет сохранять модули,
> собранные под старыми версиями perl.

Есть гарантия, что это не приведёт к крэшам при использовании
несовместимых модулей? Соответствие ABI проверяется при
динамической загрузке?

> > это тихий "вывод из обращения" модулей, утративших совместимость.
> 
> Если этот модуль кто-то использует, то тихого вывода из обращения не
> получится. То есть, в этом, конечно, есть смысл, но это противоречит
> идеалам создания дистрибутива с сильным контролем зависимостей.

Противоречит, но кому охота прописывать зависимость от версии
perl во все пакеты?
Или жёстко (полу-)автоматически привязывать пакеты к версии
perl и при смене этой версии всё пересобирать?

> > > Есть претензии
> > > и по существу механизма: возможна ситуация, когда старое дерево
> > > библиотек совместимо с новым перлом лишь частично. Это мы имеем сейчас в
> > > связи с изменениями в ABI.
> > 
> > Очевидно, если хоть какие-то модули могли оказаться несовместимыми,
> > всё дерево нужно объявлять несовместимым.
> 
> Это явная ошибка в дизайне inc_version_list (нужно было сделать две
> таких директивы, одну для privlib, другую для archlib).
> Ошибка в
> дизайне -- это ещё одна причина, по которой я счел возможным отказаться
> от использования inc_version_list. Нам не нужны ошибочные решения. :)

Это не ошибка, а недоработка, и с задачей, для которой фича была
введена, она справляется хотя бы частично.

> > > причины: а) теперь все сборки будут с тредами; во всяком случае, нужны
> > > будут очень веские причины, чтобы отказаться от сборки с тредами
> > 
> > Например, стойкая несовместимость с тредами какой-либо библиотеки,
> > которую использует какой-либо модуль.
> 
> Да, это есть весьма веская причина.
> Вместе с тем, это есть намек на пример, которого нет.
> 
> Страшно другое: для других пакетов сборка с тредами может быть бинарно
> несовместима со сборкой без тредов. Так это или нет, я не знаю, и пока
> даже не знаю, как узнать. Вы не в курсе?

Нет, но скорее всего, несовместима.

> > > название каталога в любом случае условно и не всегда/не вполне
> > > соответствует действительности.
> > 
> > Оно соответствует некоторому выбору флагов при сборке, который стоит
> > отличать от других возможных наборов флагов.
> 
> Это имеет смысл, но этим нельзя всерьёз увлекаться в дистрибутиве с
> сильным контролем зависимостей.

Не понял, при чём здесь контроль зависимостей? И что значит "сильный"?

> > В CPAN эти модули могут обновляться чаще, чем в дистрибутиве.
> 
> Однако бундель перед релизом тестируется, а CPAN -- это просто
> лавочка по агрегации частных инициатив.

Ну как, без make test туда вроде бы тоже не пускают,
а в bundle выполняется тот же make test тех же модулей.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
I love treason but hate a traitor.
		-- Gaius Julius Caesar

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[at]

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.

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

[Mikhail Zabaluev]

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

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: perl ABI detection at find-requires stage

[at]

On Sat, Oct 19, 2002 at 01:38:46PM +0400, Mikhail Zabaluev wrote:
> Их просто нужно вынести в отдельные пакеты по аналогии с CPAN.
> Дробление здесь оправдано наличием зависимостей на db и
> gdbm. 

Точно.

> SDBM_File можно оставить в главном пакете.
> То, что AnyDBM_File чего-то там не хватает, это не проблема.
> У нас же стоял при сборке AutoReq: yes, noperl :)

BTW, для AnyDBM_File формально ничего не требуется, т.к.
/usr/lib/rpm/perl.req не по зубам понять, почему ему что-то требуется.
Однако другие пакеты, которые хотят AnyDBM_File (perl-libwww-perl),
просто обломаются.

> То есть, автоматика нам эту зависимость не найдёт.
> Прописывать руками зависимость таких пакетов на libperl.so.X.Y
> можно, но это мартышкин труд.

Жестко прописать руками зависимость на ABI (на soname) -- это пока
единственный способ контролировать бинарную совместимость + целостное
состояние системы.

Во всех других случаях возможен либо крэш, либо ненайденный модуль при
установленном пакете (inc_version_list). Оба этих варианта неприемлемы,
и мы спорим только о том, насколько первый неприемлемей второго. Я
правильно понимаю?

> Впрочем, одну выгоду я осознал: noarch-пакеты не нужно пересобирать
> при смене версии perl, даже если они вышли бы из inc_version_list
> в установке "по умолчанию". Если разумно решить проблему с
> апгрейдом бинарных пакетов, возможно, всё будет Правильно.

Каким образом зависимость на ABI/soname может попасть в пакет
автоматически при сборке?

Можно ли отхачить что-нибудь на стадии find-requires так, чтобы при
обнаружении перлового бинарного кода автоматически выставлялась
зависимость на перловый soname из среды сборки?

> > 3) оставить пока libperl.so.5.8;
> > при откате назвать libperl-nothreads.so.5.8.
> > Так и сделаем.
> 
> Угу. Всё-таки неприспособленные к threads библиотеки -- это
> анахронизм, который надо изживать.

RH и MDK собирают с тредами.
Поэтому откат, действительно, маловероятен.

Re: [devel] Re: perl ABI detection at find-requires stage

[at]

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

On Sun, Oct 20, 2002 at 12:45:47AM +0400, at@turbinal.org wrote:
> Каким образом зависимость на ABI/soname может попасть в пакет
> автоматически при сборке?
> 
> Можно ли отхачить что-нибудь на стадии find-requires так, чтобы при
> обнаружении перлового бинарного кода автоматически выставлялась
> зависимость на перловый soname из среды сборки?

Я посмотрел, и мне кажется, что сделать это вполне возможно.  Для этого
проще всего ввести ещё одну стадию поиска зависимостей (и назвать её
как-нибудь perlbin/noperlbin).

Критерии:

1) если в $RPM_BUILD_ROOT/usr/lib/perl* в принципе найдены какие-нибудь
перловые модули (*.pm, "Perl5 module source text"), то
2) если в $RPM_BUILD_ROOT/usr/lib/perl*/auto/* найдены какие-нибудь
.so-библиотеки, то
3) возможный дополнительный критерий: названия *.pm и *.so должны
соответствовать друг другу
4) передать список таких .so-файлов в скрипт perlbin.req, который
напечатает что-нибудь хорошее о свойствах перла в окружении сборки

Последнего, однако, не стоит делать, если
1) в $RPM_BUILD_ROOT/usr/lib или $RPM_BUILD_ROOT/usr/lib/perl*/CORE
найдены библиотеки libperl*.so*; и, кроме того
2) найден перловый модуль $RPM_BUILD_ROOT/usr/lib/perl*/Config.pm; тогда
нужно
3) передать этот перловый модуль в скрипт perlbin.prov, который
напечатает что-нибудь хорошее о свойствах собираемого перла

Я не знаю, насколько это хорошо и стоит ли это делать вообще. Но это
поможет автоматический контролировть бинарную совместимость перловых
пакетов. Простейший возможный скрипт perlbin.req, который даже не
потребует скрипта perlbin.prov, прилагается.

[-- Attachment #2: perlbin.req --]
[-- Type: text/plain, Size: 110 bytes --]

#!/usr/bin/perl
#
# Show perl version/build-specific binary token
#

use Config;
print "$Config{libperl}\n";

[devel] Re: perl ABI detection at find-requires stage

[Mikhail Zabaluev]

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

Hello at,

On Sun, Oct 20, 2002 at 04:06:58AM +0400, at@turbinal.org wrote:
>
> On Sun, Oct 20, 2002 at 12:45:47AM +0400, at@turbinal.org wrote:
> > Каким образом зависимость на ABI/soname может попасть в пакет
> > автоматически при сборке?
> > 
> > Можно ли отхачить что-нибудь на стадии find-requires так, чтобы при
> > обнаружении перлового бинарного кода автоматически выставлялась
> > зависимость на перловый soname из среды сборки?
> 
> Я посмотрел, и мне кажется, что сделать это вполне возможно.  Для этого
> проще всего ввести ещё одну стадию поиска зависимостей (и назвать её
> как-нибудь perlbin/noperlbin).
> 
> Критерии:
> 
> 1) если в $RPM_BUILD_ROOT/usr/lib/perl* в принципе найдены какие-нибудь
> перловые модули (*.pm, "Perl5 module source text"), то
> 2) если в $RPM_BUILD_ROOT/usr/lib/perl*/auto/* найдены какие-нибудь
> .so-библиотеки, то

Достаточно поискать в $RPM_BUILD_ROOT%perl_sitearch/auto

> 3) возможный дополнительный критерий: названия *.pm и *.so должны
> соответствовать друг другу

1) и 3) практически не обязательны

> 4) передать список таких .so-файлов в скрипт perlbin.req, который
> напечатает что-нибудь хорошее о свойствах перла в окружении сборки
> 
> Последнего, однако, не стоит делать, если
> 1) в $RPM_BUILD_ROOT/usr/lib или $RPM_BUILD_ROOT/usr/lib/perl*/CORE
> найдены библиотеки libperl*.so*; и, кроме того
> 2) найден перловый модуль $RPM_BUILD_ROOT/usr/lib/perl*/Config.pm; тогда
> нужно
> 3) передать этот перловый модуль в скрипт perlbin.prov, который
> напечатает что-нибудь хорошее о свойствах собираемого перла

Для одного пакета не стоит утруждаться автоматикой.

> 
> Я не знаю, насколько это хорошо и стоит ли это делать вообще. Но это
> поможет автоматический контролировть бинарную совместимость перловых
> пакетов. Простейший возможный скрипт perlbin.req, который даже не
> потребует скрипта perlbin.prov, прилагается.

> #!/usr/bin/perl
> #
> # Show perl version/build-specific binary token
> #
> 
> use Config;
> print "$Config{libperl}\n";

На мой взгляд, скрипт правильный.
Можно даже не оформлять как отдельный скрипт, а просто, в случае
обнаружения файлов, выполнять
perl -MConfig -e 'print "$Config{libperl}\n"'

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
... mindreading equipment is currently classified CIA property at
best (hello echelon!)

	- Alan Cox on linux-kernel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Anton V. Boyarshinov]

Добрый день

On Sat, 19 Oct 2002 13:38:46 +0400
Mikhail Zabaluev <mhz@altlinux.org> wrote:

> > Да, наверное, стоит сделать perl-CPAN.
> 
> Его можно будет отчудить от perl совсем,
> проставив его собственную версию. Тогда его можно будет
> и брать с зеркал CPAN, если будут выходить обновлённые
> версии.

Тут есть такой тонкий момент: если человек пользуется CPAN.pm, то
все зависимости rpm для perl всё равно идут лесом, поэтому что
выделять его, что не выделять -- разницы большой нет. Но, ИМХО,
было бы удобно, чтобы модули, входящие в стандартную потавку
perl, в дистрибутиве не отдалялись от него слишком далеко.

> > Если вы предлагаете оставить inc_version_list, скажите об
> > этом явно.
> 
> Если других надёжных способов нет, почему бы не оставить
> inc_version_list как его разумеют авторы perl? В конце
> концов, все эти радикальные отличия вводят в смущение
> пользователей, которые привыкли к тому, как оно
> обычно устроено.

Я предлагаю оставить. Я не вижу никакого улучшения от его
убирания, а стандартное поведение -- не так уж и плохо.


> Впрочем, одну выгоду я осознал: noarch-пакеты не нужно
> пересобирать при смене версии perl, даже если они вышли бы из
> inc_version_list в установке "по умолчанию". Если разумно
> решить проблему с апгрейдом бинарных пакетов, возможно, всё
> будет Правильно.

Perl 5.6.1 умеет искать модули в каталоге 5.6.0 (если это ему
сказать при сборке). Авторы Perl тоже позаботлись об этом.
 
> > 3) оставить пока libperl.so.5.8;
> > при откате назвать libperl-nothreads.so.5.8.
> > Так и сделаем.
> 
> Угу. Всё-таки неприспособленные к threads библиотеки -- это
> анахронизм, который надо изживать.

Идеализм тоже надо изживать. Кому анахронизм, а кому без них --
никак.

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
  9:52am  up 5 days, 22:50,  3 users,  load average: 0.00, 0.05,
0.09

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

[Alexey I. Froloff]

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

On Mon, Oct 21, 2002 at 10:00:00AM +0400, Anton V. Boyarshinov wrote:
> Тут есть такой тонкий момент: если человек пользуется
> CPAN.pm, то все зависимости rpm для perl всё равно идут
> лесом, поэтому что выделять его, что не выделять -- разницы
> большой нет.
Слегка не в тему, есть ли такая возможность скачать тарболл с
модулем из CPAN? Только тарболл и только скачать, не
распаковывая.

И кстати, куда пропал cpanflute из rpm (это
вопрос Дмитрию)...

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Dmitry V. Levin]

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

On Mon, Oct 21, 2002 at 11:26:36PM +0400, Alexey I. Froloff wrote:
> И кстати, куда пропал cpanflute из rpm (это
> вопрос Дмитрию)...

rpm-contrib (за ненадобностью).


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: perl inc_version_list

[at]

On Mon, Oct 21, 2002 at 10:00:00AM +0400, Anton V. Boyarshinov wrote:
> > > Да, наверное, стоит сделать perl-CPAN.
> > 
> > Его можно будет отчудить от perl совсем,
> > проставив его собственную версию. Тогда его можно будет
> > и брать с зеркал CPAN, если будут выходить обновлённые
> > версии.
> 
> Тут есть такой тонкий момент: если человек пользуется CPAN.pm, то
> все зависимости rpm для perl всё равно идут лесом, поэтому что

Нет, в новых версиях, как я сегодня уже писал, предусмотрено
разделение каталогов vendor_perl (модули из дистрибутива) и site_perl
(модули, установленные самостоятельно в /usr/local).

По смылсу, inc_version_list нужно сохранить только для site_perl, т.е.
как раз для тех, кто хочет активно пользоваться CPAN.pm. 

> > > Если вы предлагаете оставить inc_version_list, скажите об
> > > этом явно.
> > 
> > Если других надёжных способов нет, почему бы не оставить
> > inc_version_list как его разумеют авторы perl? В конце
> > концов, все эти радикальные отличия вводят в смущение
> > пользователей, которые привыкли к тому, как оно
> > обычно устроено.
> 
> Я предлагаю оставить. Я не вижу никакого улучшения от его
> убирания, а стандартное поведение -- не так уж и плохо.

Рассмотрим ситуацию:

Пакет(ы) perl-*5.6.1-*.rpm предоставляют каталоги
/usr/lib/perl5/site_perl/5.6.1
/usr/lib/perl5/site_perl/5.6.1/i386-linux

Пакет(ы) perl-*5.8.0-*.rpm предоставляют каталоги
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux

После обновления как минимум первый из всех каталогов не может быть
удален, т.к. в нем остаются модули, совместимые с новыми пакетами (кроме
того, каталоги могут не удаляться из-за неправильного порядка удаления
пакетов).

Последствия:

1) в /usr/lib существует каталог, который не принадлежит ни одному
пакету;

2) оставшиеся вполне целостными (как пакеты) перловые модули начинают
вдруг лежать в ничейном каталоге; таким образом, обновление в некотором
смысле задевает и другие пакеты; хочу также заметить, что перловым
модулям от этого станет очень непривычно и даже обидно, т.к. хорошие
пакеты не должны лежать в ничейных каталогах;

3) каталог этот не будет удален даже тогда, когда (со временем)
освободится, т.к. rpm "не помнит" о том, что он кому-то принадлежал.

Таким образом, при обновлении нарушается целостность системы. В
сущности, это такая же ошибка, как и потерянные при обновлении каталоги
в /usr/share/doc (эта ошибка недавно обсуждалась). Отличается она только
тем, что каталог остается непустым, и поэтому не существует
"правильного" решения, которое позволило бы исправить эту ошибку.
Неверен сам механизм использования версии в названии каталога, в который
впоследствии буду ставиться другие пакеты, обладающие некоторой
совместимостью.

> Идеализм тоже надо изживать. Кому анахронизм, а кому без них --
> никак.

Анахронизм есть запуск привилегированного демона, который в случайные
моменты времени с очень малой вероятностью посылает сигналы SIGKILL
процессам со случайным pid'ом.

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

[Mikhail Zabaluev]

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

Hello Anton,

On Mon, Oct 21, 2002 at 10:00:00AM +0400, Anton V. Boyarshinov wrote:
>
> > Угу. Всё-таки неприспособленные к threads библиотеки -- это
> > анахронизм, который надо изживать.
> 
> Идеализм тоже надо изживать. Кому анахронизм, а кому без них --
> никак.

Здесь нужны примеры.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Hartley's First Law:
	You can lead a horse to water, but if you can get him to float
	on his back, you've got something.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Anton V. Boyarshinov]

Добрый день

On Tue, 22 Oct 2002 02:52:28 +0400
Mikhail Zabaluev <mhz@altlinux.org> wrote:

> Hello Anton,
> 
> On Mon, Oct 21, 2002 at 10:00:00AM +0400, Anton V. Boyarshinov
> wrote:
> >
> > > Угу. Всё-таки неприспособленные к threads библиотеки -- это
> > > анахронизм, который надо изживать.
> > 
> > Идеализм тоже надо изживать. Кому анахронизм, а кому без них
> > -- никак.
> 
> Здесь нужны примеры.

http://www.perl.com/pub/a/2002/09/04/threads.html?page=4

Modules

In general, unless a module has been specifically vetted as
thread safe it cannot be used in a threaded program. Most pure
Perl modules should be thread safe but most XS modules are not.
This goes for core modules too!

An earlier version of the elevator simulator used Time::HiRes to
allow for fractional sleep() times. This really helped speed up
the simulation since it meant that elevators could traverse more
than one floor per second. However, on further investigation (and
advice from Nick Ing-Simmons) I realized that Time::HiRes is not
necessarily thread safe. Although it seemed to work fine on my
machine there's no reason to believe that would be the case
elsewhere, or even that it wouldn't blow up at some random point
in the future. The problem with thread safety is that it's
virtually impossible to test for; either you can prove you have
it or you must assume you don't!

Из этого следует что большинство модулей с С кодом не
thread-safe.
Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 10:20am  up 6 days, 23:18,  3 users,  load average: 0.21, 0.24,
0.25

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

[Alexey Tourbin]

On Tue, Oct 22, 2002 at 10:25:07AM +0400, Anton V. Boyarshinov wrote:
> In general, unless a module has been specifically vetted as
> thread safe it cannot be used in a threaded program. Most pure
> Perl modules should be thread safe but most XS modules are not.
> This goes for core modules too!

"Most XS modules are not" означает, что эти модули нельзя использовать в
перловой программе, которая непосредственно использует треды; точнее,
эти модули нельзя использовать в распаралеленном коде, т.к. в них могут
использоваться статические буферы и т.п. Это и есть thread-unsafe.

use threads;
for $n (1..10) {
	async {
		# здесь работать не будет
		XSLibrary->static_function($n);
	}
}

Это, однако, не значит, что эти модули вообще не будут работать, если
перл собран с поддержкой тредов.

Re: [devel] Re: perl thread safety

[at]

On Tue, Oct 22, 2002 at 05:08:49PM +0400, Alexey Tourbin wrote:
> Это, однако, не значит, что эти модули вообще не будут работать, если
> перл собран с поддержкой тредов.

Итак, я пересобрал несколько своих XS модулей, о которых мне хорошо
известно, что они thread-unsafe, т.к. в них используются статические
итераторы и т.п. Даже на очень больших нагрузках всё работает очень
мило.

Кроме того, у меня сложилось впечатление, что новый перл работает
ощутимо быстрее. Наверное, это связано в том числе и с gcc3.2.

[devel] Re: perl/Junior

[at]

On Sat, Oct 19, 2002 at 02:26:12AM +0400, Mikhail Zabaluev wrote:
> его c perl-base. Пользователям Junior может стать
> обидно, что perl у них есть, но умеет явно меньше,
> чем то, что про него пишут в книжках.

Есть и много других причин, по которым пользователям Junior может вдруг
стать обидно. :) И в книжках пишут не только о перле. Я так понимаю, что
Junior -- это ознакомительная система, с упором на desktop. Если
пользователю нужно что-то больше, он сможет установить это из сизифа.
Учитывая то, что размеры пакетов только растут, а размеры болванок
остаются прежними, -- выбора здесь особо нет.

Впрочем, к Junior есть ещё и Appendix. В него-то наверное и стоит
включить несколько дополнительных perl-* пакетов.

> Если уж есть нужда в настолько минималистичной инсталляции,
> то perl там вообще лишний.

Перл может пригодиться и в минималистичных инсталляциях. Дело только в
том, что большинству пакетов нужно не более 10% того, что входит в
bundle. Поэтому имеет смысл делать perl-base. И действительно, это
практически полнофункциональный перл. Большую часть места занимает
документация, локализация, локали, перекодировки и т.п.

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

[Michael Shigorin]

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

On Sat, Oct 19, 2002 at 02:26:12AM +0400, Mikhail Zabaluev wrote:
> > Само разбиение в таком случае теряет смысл, и получается, что
> > лучше честно собирать perl одним пакетом, как RH.

Товарищи бсдишники вот грозились подбросить ссылки на обсуждение
такого предмета, как "если это не ВЕСЬ перл -- вы не имеете права
называть это perl".  Есть подозрение, что политика RH может быть
не в последнюю очередь и минимализацией потенциала подобных
проблем.

Насколько я понимаю, у них (fbsd) из basesystem перл потому и
выносили, что отпилить немного -- нельзя, помимо всего.

> Пользователям Junior может стать обидно, что perl у них есть,
> но умеет явно меньше, чем то, что про него пишут в книжках.

Ни-ни, писать в книжках могут что угодно.  В /dev/forest. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

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

[at]

On Sun, Oct 20, 2002 at 04:37:21PM +0300, Michael Shigorin wrote:
> > > Само разбиение в таком случае теряет смысл, и получается, что
> > > лучше честно собирать perl одним пакетом, как RH.
> 
> Товарищи бсдишники вот грозились подбросить ссылки на обсуждение
> такого предмета, как "если это не ВЕСЬ перл -- вы не имеете права
> называть это perl".

Увы, это называется perl-base, поэтому почвы для обсуждения нет.

> Есть подозрение, что политика RH может быть
> не в последнюю очередь и минимализацией потенциала подобных
> проблем.

Не стоит сравнивать RH с BSD, т.к. BSD -- это монолитная система
(cvsup), a RH полностью построен на основе RPM. Скорее, RH просто
плывает по течению. И перлом, к тому же, в RH никогда не увлекались.

Pure RH6.2:

$ rpm -qa | grep perl
groff-perl-1.15-8
perl-5.00503-10
mod_perl-1.21-10
$

> Насколько я понимаю, у них (fbsd) из basesystem перл потому и
> выносили, что отпилить немного -- нельзя, помимо всего.

Чем обусловлено Ваше понимание? :) 
Я проанализировал и пришел к выводу, что можно.

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

[Mikhail Zabaluev]

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

Hello at,

On Mon, Oct 21, 2002 at 06:12:45AM +0400, at@turbinal.org wrote:
>
> Pure RH6.2:
> 
> $ rpm -qa | grep perl
> groff-perl-1.15-8
> perl-5.00503-10
> mod_perl-1.21-10

Это потому, что пакеты с модулями у них называются не
perl-Some-Module, как в Mandrake, а просто Some-Module.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Show me a man who is a good loser and I'll show you a man who is playing
golf with his boss.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[at]

On Sat, Oct 19, 2002 at 02:26:12AM +0400, Mikhail Zabaluev wrote:
> > Это явная ошибка в дизайне inc_version_list (нужно было сделать две
> > таких директивы, одну для privlib, другую для archlib).
> > Ошибка в
> > дизайне -- это ещё одна причина, по которой я счел возможным отказаться
> > от использования inc_version_list. Нам не нужны ошибочные решения. :)
> 
> Это не ошибка, а недоработка, и с задачей, для которой фича была
> введена, она справляется хотя бы частично.

Главное же, я стал сомневаться в невозможности включить в
inc_version_list только privlib, как стал я сомневаться и в своем
утверждении о явной ошибке.

Я работаю над этой проблемой. :)