[devel] Re: perl inc_version_list

[=?iso-8859-1?q?at_=CE=C1_turbinal=2Eorg?=]

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'ом.