Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Alexey Tourbin]

On Mon, Oct 24, 2011 at 11:38:22AM +0400, Girar Builder robot wrote:
> http://git.altlinux.org/tasks/archive/done/_55/56408/logs/events.52.2.log

Мужчины, я собрал perl-5.14!  А также обновил или пересобрал все бинарно
зависимые пакеты.  Крупных разломов не предвидится.

Основное изменение - организационное: я расконвертировал большую часть
своих перловых пакетов из git в src.rpm.  Это связано с тем, что эти
пакеты будут обновляться роботом, о чем разговоры идут давно, а теперь
имеются и некоторые предварительные договоренности.  По этой же причине
я взял на себя смелость расконвертировать и чужие перловые пакеты, а также
привести спек-файлы к более унифицированному виду.  Про автоматическое
обновление пакетов - чуть ниже.

Расконвертирование и унификация коснулись только перловых пакетов,
публикуемых на CPAN, включая проекты с отдельным сайтом, такие как
gtk2-perl.sf.net, которые тем не менее регулярно выкладываются на CPAN.
С остальными пакетами я обходился осторожно.

Пару слов про пересборку пакетов под perl-5.14.  Во-первых, несколько
API-макросов перестали давать lvalue, которому можно присваивать.
Типичное исправление выглядит так:

	-	GvCV(sv) = NULL;
	+	GvCV_set(sv, NULL);

Ещё не все апстримы успели выпустить версии с исправлениями такого рода;
а некоторые выпустили только совсем недавно.  Поэтому, например, я решил
сразу во время пересборки обновить postgresql с версии 9.0.4 до 9.0.5.

Во-вторых, и это очень важно, перловый код теперь должен компилироваться
с родными для перла CCFLAGS.  Точнее, на архитектуре i586 весь перловый
код должен компилироваться с флагом -D_FILE_OFFSET_BITS=64.  Это связано
с тем, что в структуре "struct interpreter" имеется поле "struct stat",
размер которого зависит от _FILE_OFFSET_BITS.  Соответственно, когда мы
хотим прочитать какие-то поля из "struct interpreter", которые расположены
после "struct stat", то без правильного значения _FILE_OFFSET_BITS можно
промахнуться и прочитать совсем не то.  В результате может при загрузке
модуля может появиться такое сообщение об ошибке:
	
	Not a CODE reference at /usr/lib/perl/DynaLoader.pm line 207

Типичное исправление может выглядеть так (spec):

	# do not override default CCFLAGS
	sed -i '/CCFLAGS/d' Makefile.PL

или так (Makefile.PL):

		use Config;
		...
	-	CCFLAGS => $cflags,
	+	CCFLAGS => $cflags . ' ' . $Config{ccflags},

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

* * *

Некоторые соображения об автоматической сборке пакетов.

Понятно, что среди всех пакетов перловые пакеты наилучшим образом подходят
для автоматической сборки.  Потому что процедура сборки пакетов
унифицирована, потому что почти все пакеты содержат тесты, которые
выполняются при сборке по умолчанию; а при поиске зависимостей ещё
выполняется syntax check - короче, получить битый пакет не так-то просто.
Потому что CPAN отдаёт информацию о пакетах в актуальном структурированном
виде.  И, не в последнюю очередь, потому что перловых пакетов много - 1350+,
то есть почти 11% от общего числа, если считать src.rpm пакеты в сизифе.

Что должен и чего не должен делать робот, чтобы обновить пакет?  Моё
представление об этом такое.  Рассмотрим робота первой инкарнации v1.0.
Этот робот должен делать следующее: скачать новый тарболл в каталог
SOURCES, изменить версию в спекфайле, и попытаться получить src.rpm пакет.
Нужно проверить, что в полученный src.rpm пакет "всосался" новый тарболл -
это произойдёт, если поле Source в спекфайле параметризовано.  Тогда
полученный src.rpm пакет можно отправлять на сборку.

Суть в том, что больше робот v1.0 вообще ничего делать не должен.
Не должен смотреть даже ниже поля Version в спекфайле!  К сожалению,
робот, с которым мне приходилось сталкиваться, ведёт себя слишком
остроумно: первым делом редактирует поле Source и часто добавляет
зависимость на perl(Module/Build.pm), причём в неподобающем месте.
И вообще демонстрирует неуёмную тягу к редактированию спекфайла.

Вообще, у робота не должно быть задачи максимизировать число пакетов,
которые он с грехом пополам может автоматически обновить.  А именно, должна
быть четкая линия демаркации - это навеяно идеями Поппера - что существует
штатная ситуация и класс пакетов, которые поддаются автоматическому
обновлению, а остальные пакеты автоматическому обновлению не поддаются,
т.к. требуется квалифицированное вмешательство.  Соответственно, сдвигать
линию демаркации вправо - это авантюрная идея; а робот, который может
обновить любой пакет несмотря ни на что - это плохой, негодный робот.

Рассмотрим робота следующей инкарнации, v2.0.  Что ещё полезного может
сделать робот?  Наверное, все же стоит попытаться собрать пакет в хешере,
прежде чем отправлять его на сборку.  Но стоит ли, например, проверять
после этого неудовлетворенные зависимости?  Полноценная проверка требует
перегенерации репозитория (для замещения пакетов).

Вообще, робот сидит в своем маленьком мирке и выполняет некоторый
ограниченный набор операций по комплектованию пакетов.  А сборочная
система для робота трансцендентна, какие проверки там дальше будут
выполняться, это для робота непостижимо.  Но всё же робот контролирует
некоторую первичную реальность, из которой потом получается смысловая
реальность.

Эти смутные рассуждения наводят меня на мысль, что робот должен
контролировать список файлов в собранных пакетов.  А именно, в простейшем
случае в хешере робот должен собирать пакеты с опцией
_unpackaged_files_terminate_build.  А лучше будет сравнивать сборку
старого и нового пакетов: если появились новые незапакованные файлы,
то скорее всего мы получаем недоукомплектованный пакет (и такой пакет
нельзя отправлять на сборку).

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

Кроме того, есть ещё один неприятный момент, который можно назвать
переукомплектацией.  Дело в том, что *.pl файлы, находящиеся в основном
каталоге, по правилам MakeMaker устанавливаются в /usr/*/perl5/Foo/,
наряду с lib/ и другими файлами.  Так что в дерево модулей иногда
попадают файлы типа /usr/*/perl5/Foo/benchmark.pl или Bar/bug123.pl,
которые порождают левые зависимости.  Так что это даёт ещё одно правило
для робота: если появились файлы /usr/*/perl5/*/*.pl, которых раньше не
было, то не следует автоматически отправлять пакет на сборку.

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Dmitry V. Levin]

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

On Tue, Oct 25, 2011 at 02:36:31AM +0400, Alexey Tourbin wrote:
[...]
> Во-вторых, и это очень важно, перловый код теперь должен компилироваться
> с родными для перла CCFLAGS.  Точнее, на архитектуре i586 весь перловый
> код должен компилироваться с флагом -D_FILE_OFFSET_BITS=64.  Это связано
> с тем, что в структуре "struct interpreter" имеется поле "struct stat",
> размер которого зависит от _FILE_OFFSET_BITS.  Соответственно, когда мы
> хотим прочитать какие-то поля из "struct interpreter", которые расположены
> после "struct stat", то без правильного значения _FILE_OFFSET_BITS можно
> промахнуться и прочитать совсем не то.  В результате может при загрузке
> модуля может появиться такое сообщение об ошибке:
> 	
> 	Not a CODE reference at /usr/lib/perl/DynaLoader.pm line 207

Почему бы не вставить в файл, определяющий структуру "struct interpreter",
защиту от неправильной компиляции?

[после #include <sys/stat.h>]
#if defined(__i386__) && defined(__GLIBC__) && !defined(__USE_FILE_OFFSET64)
# if __WORDSIZE == 32
#  error "<файл.h> cannot be used without -D_FILE_OFFSET_BITS==64"
# endif
#endif


-- 
ldv

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

Re: [devel] perl.h -D_FILE_OFFSET_BITS=64

[Dmitry V. Levin]

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

On Tue, Oct 25, 2011 at 03:18:04AM +0400, Dmitry V. Levin wrote:
> On Tue, Oct 25, 2011 at 02:36:31AM +0400, Alexey Tourbin wrote:
> [...]
> > Во-вторых, и это очень важно, перловый код теперь должен компилироваться
> > с родными для перла CCFLAGS.  Точнее, на архитектуре i586 весь перловый
> > код должен компилироваться с флагом -D_FILE_OFFSET_BITS=64.  Это связано
> > с тем, что в структуре "struct interpreter" имеется поле "struct stat",
> > размер которого зависит от _FILE_OFFSET_BITS.  Соответственно, когда мы
> > хотим прочитать какие-то поля из "struct interpreter", которые расположены
> > после "struct stat", то без правильного значения _FILE_OFFSET_BITS можно
> > промахнуться и прочитать совсем не то.  В результате может при загрузке
> > модуля может появиться такое сообщение об ошибке:
> > 	
> > 	Not a CODE reference at /usr/lib/perl/DynaLoader.pm line 207
> 
> Почему бы не вставить в файл, определяющий структуру "struct interpreter",
> защиту от неправильной компиляции?
> 
> [после #include <sys/stat.h>]
> #if defined(__i386__) && defined(__GLIBC__) && !defined(__USE_FILE_OFFSET64)
> # if __WORDSIZE == 32
> #  error "<файл.h> cannot be used without -D_FILE_OFFSET_BITS==64"
> # endif
> #endif

Это подход работает, предлагаю собрать в Сизиф
http://git.altlinux.org/people/ldv/packages/?p=perl.git;a=commitdiff;h=5.14.2-alt1-2-g7152efd


-- 
ldv

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

Re: [devel] perl.h -D_FILE_OFFSET_BITS=64

[Dmitry V. Levin]

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

On Sun, Oct 30, 2011 at 03:40:05AM +0400, Dmitry V. Levin wrote:
> On Tue, Oct 25, 2011 at 03:18:04AM +0400, Dmitry V. Levin wrote:
> > On Tue, Oct 25, 2011 at 02:36:31AM +0400, Alexey Tourbin wrote:
> > [...]
> > > Во-вторых, и это очень важно, перловый код теперь должен компилироваться
> > > с родными для перла CCFLAGS.  Точнее, на архитектуре i586 весь перловый
> > > код должен компилироваться с флагом -D_FILE_OFFSET_BITS=64.  Это связано
> > > с тем, что в структуре "struct interpreter" имеется поле "struct stat",
> > > размер которого зависит от _FILE_OFFSET_BITS.  Соответственно, когда мы
> > > хотим прочитать какие-то поля из "struct interpreter", которые расположены
> > > после "struct stat", то без правильного значения _FILE_OFFSET_BITS можно
> > > промахнуться и прочитать совсем не то.  В результате может при загрузке
> > > модуля может появиться такое сообщение об ошибке:
> > > 	
> > > 	Not a CODE reference at /usr/lib/perl/DynaLoader.pm line 207
> > 
> > Почему бы не вставить в файл, определяющий структуру "struct interpreter",
> > защиту от неправильной компиляции?
> > 
> > [после #include <sys/stat.h>]
> > #if defined(__i386__) && defined(__GLIBC__) && !defined(__USE_FILE_OFFSET64)
> > # if __WORDSIZE == 32
> > #  error "<файл.h> cannot be used without -D_FILE_OFFSET_BITS==64"
> > # endif
> > #endif
> 
> Это подход работает, предлагаю собрать в Сизиф
> http://git.altlinux.org/people/ldv/packages/?p=perl.git;a=commitdiff;h=5.14.2-alt1-2-g7152efd

http://git.altlinux.org/people/ldv/packages/?p=perl.git;a=commitdiff;h=5.14.2-alt2-1-g3a07420
Повторно предлагаю собрать это изменение в Сизиф.  Если есть
аргументированные возражения по поводу этого изменения, пожалуйста,
не скрывайте их от нас, изложите их здесь.


-- 
ldv

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

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[thecrux]

On Tue, Oct 25, 2011 at 02:36:31AM +0400, Alexey Tourbin wrote:
> On Mon, Oct 24, 2011 at 11:38:22AM +0400, Girar Builder robot wrote:
> > http://git.altlinux.org/tasks/archive/done/_55/56408/logs/events.52.2.log
> 
> Мужчины, я собрал perl-5.14!  А также обновил или пересобрал все бинарно
> зависимые пакеты.  Крупных разломов не предвидится.

Отличная работа, Алексей!

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Michael Shigorin]

On Tue, Oct 25, 2011 at 02:36:31AM +0400, Alexey Tourbin wrote:
> Мужчины, я собрал perl-5.14!  А также обновил или пересобрал
> все бинарно зависимые пакеты.  Крупных разломов не предвидится.

Поздравляю и спасибо тебе :)

> * * *
> 
> Что должен и чего не должен делать робот, чтобы обновить пакет?
> Моё представление об этом такое.

Возможно, мнения по этому поводу варьируют в зависимости от того,
кому какая перловка попадается.

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

Возможно, когда-то у нас будут разные роботы.  Люди и задачи
есть точно разные.  В contrib могли бы собирать и более
авантюристические экземпляры.

> [...] что робот должен контролировать список файлов в собранных
> пакетов.  А именно, в простейшем случае в хешере робот должен
> собирать пакеты с опцией _unpackaged_files_terminate_build. [...]

Угу.

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

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Igor Vlasenko]

On Tue, Oct 25, 2011 at 02:36:31AM +0400, Alexey Tourbin wrote:
> On Mon, Oct 24, 2011 at 11:38:22AM +0400, Girar Builder robot wrote:
> > http://git.altlinux.org/tasks/archive/done/_55/56408/logs/events.52.2.log
> 
> Мужчины, я собрал perl-5.14!  А также обновил или пересобрал все бинарно
> зависимые пакеты.  Крупных разломов не предвидится.

Хорошая работа, мои поздравления.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Igor Vlasenko]

On Tue, Oct 25, 2011 at 02:36:31AM +0400, Alexey Tourbin wrote:
> Некоторые соображения об автоматической сборке пакетов.

[...]
Ок, список пожаланий принят.

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

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

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

Чтобы им можно было пользоваться всем желающим.
Чтобы быстрее и удобнее было выучить начала perl плюс познакомиться
с примерами и документацией на специализированный язык,
чем выполнять какую-то операцию вручную над 20+ пакетами
или писать свой робот с нуля.

Пока у меня фаза продумывания и стабилизации.

На примере пожеланий Алексея к роботу.
Как бы я постарался реализовать эти пожелания.

Тупое обновление версии встроено в утилиту srpmnmu.
Допустим, скачали новые исходники
$ wget -c 'http://cpan.org.ua/authors/id/J/JF/JFEARN/XML-TreeBuilder-4.1.tar.gz'

теперь вызываем 
$ srpmnmu --changelog '- CPAN update' --version 4.1 \
 --copy_to_sources ./XML-TreeBuilder-4.1.tar.gz \
/var/ftp/pub/Linux/ALT/Sisyphus/files/SRPMS/perl-XML-TreeBuilder-3.09-alt3.1.src.rpm
Записан: perl-XML-TreeBuilder-4.1-alt1.src.rpm

Теперь, например, хотим включить _unpackaged_files_terminate_build.
Создаем файл unpackaged_files_terminate_build.pl такого содержания:
-------unpackaged_files_terminate_build.pl------------
#!/usr/bin/perl
push @SPECHOOKS, 
sub {
    my ($spec) = @_;
    my $mainsec=$spec->main_section;
    $mainsec->unshift_body('%define _unpackaged_files_terminate_build 1'."\n") unless ($mainsec->match_body(qr'_unpackaged_files_terminate_build');
};
------------------------------------------------------
этот файл можно включить в предыдущий вызов с помощью опции 
 --hook unpackaged_files_terminate_build.pl
или, например, использовать его отдельно для NMU по добавлению
в пакеты этой опции. сразу на 1300+ пакетов:
$ girar-nmu-prepare --changelog '- NMU: enabled _unpackaged_files_terminate_build' --hook unpackaged_files_terminate_build.pl /ALT/Sisyphus/files/SRPMS/perl-*

Таких hook'ов можно добавить в опции сколько угодно, например, добавление 
BuildRequires: в результате анализа искходников, делая при желании 
робот более "умным", или, наоборот, не добавлять,
чтобы поведение робота было максимально тупым.

Идея в том, что специализированный язык для предметной области
позволяет гораздо проще получать новую функциональность.

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[thecrux]

On Wed, Oct 26, 2011 at 07:56:57PM +0300, Igor Vlasenko wrote:
...
> Теперь, например, хотим включить _unpackaged_files_terminate_build.
> Создаем файл unpackaged_files_terminate_build.pl такого содержания:
> -------unpackaged_files_terminate_build.pl------------
> #!/usr/bin/perl
> push @SPECHOOKS, 
> sub {
>     my ($spec) = @_;
>     my $mainsec=$spec->main_section;
>     $mainsec->unshift_body('%define _unpackaged_files_terminate_bi...
> };
> ------------------------------------------------------
> этот файл можно включить в предыдущий вызов с помощью опции 
>  --hook unpackaged_files_terminate_build.pl
> или, например, использовать его отдельно для NMU по добавлению
> в пакеты этой опции. сразу на 1300+ пакетов:
> $ girar-nmu-prepare --changelog '- NMU: enabled _unpackaged_files_...

Система хуков в таком виде смахивает на костыли и непонятно как её,
например, опакетить.
Гораздо логичнее выглядит система плагинов, расширяющая функционал
базового модуля. Подключая нужный плагин, получаешь нужный результат.
Тесты для таких плагинов писать будет значительно проще и паковать в
виде обычных perl-пакетов.

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Igor Vlasenko]

On Wed, Oct 26, 2011 at 10:14:20PM +0400, thecrux@gmail.com wrote:
> Система хуков в таком виде смахивает на костыли и непонятно как её,
> например, опакетить.
Хорошее замечание.
Например, хуки для репокопа я пакетил в
/usr/share/repocop/fixscripts.

Для общих хуков можно выделить что-то вроде 
/usr/share/srpmutils/hooks

> Гораздо логичнее выглядит система плагинов, расширяющая функционал
> базового модуля. Подключая нужный плагин, получаешь нужный результат.
> Тесты для таких плагинов писать будет значительно проще и паковать в
> виде обычных perl-пакетов.

Хук, вообще говоря, и есть простейший плагин, загружаемый через requires;
Если попытаться по-другому, в итоге выходит 
слишком много букф.
Ведь плагин надо как-то инициализировать, и вызвать.

у хука на это уходит 3 строчки, 55 символов.
-----------------------
push @SPECHOOKS, sub {
    my ($spec,$parent) = @_;
};
-----------------------
Остальное уже полезный код.

С другой стороны, есть и тяжелый код, который логично
размещать в отдельных модулях.
Хочу для такого зарезервировать namespace
RPM::Source::Tools::*

Пока там только RPM::Source::Tools::Uupdate.pm

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Igor Vlasenko]

On Wed, Oct 26, 2011 at 09:57:05PM +0300, Igor Vlasenko wrote:

Неудачно рассказал, неправильно.

хуки предназначены для "эфмерного" кода, который всегда
сиюминутный и на скорую руку.
Надо провести NMU - добавить в спекфайлы _unpackaged_files_terminate_build,
или зависимость убрать, или заменить путь макрос --
написали хук на 5 строчек, провели NMU, хук выбросили.

А для повторно используемого кода - конечно, модули.
Например, утилита srpmbackport -- frontend к модулю ALTLinuxBackport.pm,
который насдедуется от модуля Transform.pm утилиты srpmnmu.

Тот же робот сопровождения перловых пакетов удобно прототипировать
хуками, а потом по достижении искомой функциональности перенести
код из хуков в отдельный модуль.


> On Wed, Oct 26, 2011 at 10:14:20PM +0400, thecrux@gmail.com wrote:
> > Система хуков в таком виде смахивает на костыли и непонятно как её,
> > например, опакетить.
> Хорошее замечание.
> Например, хуки для репокопа я пакетил в
> /usr/share/repocop/fixscripts.
> 
> Для общих хуков можно выделить что-то вроде 
> /usr/share/srpmutils/hooks
> 
> > Гораздо логичнее выглядит система плагинов, расширяющая функционал
> > базового модуля. Подключая нужный плагин, получаешь нужный результат.
> > Тесты для таких плагинов писать будет значительно проще и паковать в
> > виде обычных perl-пакетов.
> 
> Хук, вообще говоря, и есть простейший плагин, загружаемый через requires;
> Если попытаться по-другому, в итоге выходит 
> слишком много букф.
> Ведь плагин надо как-то инициализировать, и вызвать.
> 
> у хука на это уходит 3 строчки, 55 символов.
> -----------------------
> push @SPECHOOKS, sub {
>     my ($spec,$parent) = @_;
> };
> -----------------------
> Остальное уже полезный код.
> 
> С другой стороны, есть и тяжелый код, который логично
> размещать в отдельных модулях.
> Хочу для такого зарезервировать namespace
> RPM::Source::Tools::*
> 
> Пока там только RPM::Source::Tools::Uupdate.pm

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.