From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: at@turbinal.org Date: Tue, 22 Oct 2002 00:16:22 +0400 To: devel@altlinux.ru Subject: Re: [devel] Re: perl inc_version_list Message-ID: <20021021201622.GA11754@homestead.turbinal.org> Mail-Followup-To: devel@altlinux.ru References: <20021016014557.GA29249@homestead.turbinal.org> <20021017081412.GB22143@mhz.mikhail.zabaluev.name> <20021018014056.GA4494@homestead.turbinal.org> <20021018222612.GA2153@mhz.mikhail.zabaluev.name> <20021018234241.GA5988@homestead.turbinal.org> <20021019093846.GA54@mhz.mikhail.zabaluev.name> <20021021060106.F0CA32B515@mail.ru.echo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20021021060106.F0CA32B515@mail.ru.echo.fr> 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: 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'ом.