[devel] проблемы с поиском зависимостей [2]

[devel] проблемы с поиском зависимостей [2]

[Alexey Tourbin]

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

On Thu, Mar 01, 2007 at 11:31:09PM +0300, Alexey Tourbin wrote:
> 1) вариации шарпбанга можно использовать для отключения распознавания.
> 2) find-requires и find-provides не модульные.

Я начал решал вторую проблему, и оказалось, что в процессе решения
второй проблемы в значительной степени решается и первая проблема.

Я выложил в git.alt:/people/at/packages/rpm.git бранч mod.  Основные
изменения там в основном закончены (кроме тех, которые явно не
закончены; такие, как остатки старого кода в find-requires и
find-provides).

Вкратце, как это работает.  find-requires и find-provides запускает
file(1) и скармливает его вывод в фильтры .req.files и .prov.files (от
идеи общего .files для .req и .prov пришлось отказаться).  Дальше
фильтры выводят список файлов, и этот список файлов скармливается
в .req или .prov.

Выглядит это вполне даже благовидно.
Примеры.

Вывести список шелл-файлов для поиска зависимостей из пакета rpm-utils.

$ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/shell.req.files
/usr/bin/add_changelog
/usr/bin/buildreq
/usr/bin/cleanup_spec
/usr/bin/compare_packages
/usr/bin/filereq
/usr/bin/packagereq
/usr/bin/rebuild_package
/usr/bin/rebuild_packages
/usr/bin/stamp_spec
/usr/share/buildreqs/filter_strace
/usr/share/buildreqs/strace_files
$

Найти зависимости в shell-файлах из пакета rpm-utils.

$ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/shell.req.files |/usr/lib/rpm/shell.req |sort -u
coreutils
diffutils
ed
findutils
gawk
grep
perl-base
rpm
rpm-utils
sed
strace
$

Поскольку нет билдрута, то "естественным образом" появляется зависимость
на rpm-utils.

Если в req/prov скриптах использовать опцию --verbose, то можно узнать
что-нибудь интересное.

$ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/shell.req.files |/usr/lib/rpm/shell.req -v 2>&1| head
shell.req: /usr/bin/add_changelog: cat -> /bin/cat -> ... (via which)
shell.req: /usr/bin/add_changelog: /bin/cat -> coreutils (via rpmdb)
shell.req: /usr/bin/add_changelog: ed -> /bin/ed -> ... (via which)
shell.req: /usr/bin/add_changelog: /bin/ed -> ed (via rpmdb)
shell.req: /usr/bin/add_changelog: grep -> /bin/grep -> ... (via which)
shell.req: /usr/bin/add_changelog: /bin/grep -> grep (via rpmdb)
shell.req: /usr/bin/add_changelog: rm -> /bin/rm -> ... (via which)
shell.req: /usr/bin/add_changelog: /bin/rm -> coreutils (via rpmdb)
shell.req: /usr/bin/add_changelog: sed -> /bin/sed -> ... (via which)
shell.req: /usr/bin/add_changelog: /bin/sed -> sed (via rpmdb)
$

Опция -vv может сказать ещё больше интересного, а -vvv для особо
интересующихся включит -x.

Аналогично работают другие req/prov скрипты.

$ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/lib.req.files |/usr/lib/rpm/lib.req -vv
lib.req: processing /usr/bin/packageof
rtld(GNU_HASH)
libc.so.6(GLIBC_2.4)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.2.5)
libc.so.6(GLIBC_2.0)
librpmdb-4.0.4.so
libgcc_s.so.1(GCC_3.0)
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
librpmio-4.0.4.so
librpm-4.0.4.so
lib.req: processing /usr/bin/rpmdups
rtld(GNU_HASH)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.0)
librpmdb-4.0.4.so
libgcc_s.so.1(GCC_3.0)
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
librpmio-4.0.4.so
librpm-4.0.4.so
lib.req: processing /usr/bin/rpmevrcmp
rtld(GNU_HASH)
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.3.4)
librpmdb-4.0.4.so
lib.req: processing /usr/bin/rpmrdups
rtld(GNU_HASH)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.0)
librpmdb-4.0.4.so
libgcc_s.so.1(GCC_3.0)
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
librpmio-4.0.4.so
librpm-4.0.4.so
lib.req: processing /usr/bin/rpmvercmp
rtld(GNU_HASH)
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.3.4)
librpmdb-4.0.4.so
$ 

Выборочная пересборка нескольких пакетов дала идентичные зависимости.

Кроме того, пакет git не собирается, потому что там в некоторых
шелл-скриптах после `exit 0' идет некомментированный plain text.

Кроме того, будут проблемы с питоном, потому что `#!/usr/bin/env python'
теперь отыскиваются слишком хорошо.  Всё это я готов обсудить вечером,
если буду не слишком пьян от своих скромных успехов.

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

Re: [devel] проблемы с поиском зависимостей [2]

[Dmitry V. Levin]

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

On Mon, Mar 12, 2007 at 03:36:30PM +0300, Alexey Tourbin wrote:
> On Thu, Mar 01, 2007 at 11:31:09PM +0300, Alexey Tourbin wrote:
> > 1) вариации шарпбанга можно использовать для отключения распознавания.
> > 2) find-requires и find-provides не модульные.
> 
> Я начал решал вторую проблему, и оказалось, что в процессе решения
> второй проблемы в значительной степени решается и первая проблема.
> 
> Я выложил в git.alt:/people/at/packages/rpm.git бранч mod.  Основные
> изменения там в основном закончены (кроме тех, которые явно не
> закончены; такие, как остатки старого кода в find-requires и
> find-provides).
> 
> Вкратце, как это работает.  find-requires и find-provides запускает
> file(1) и скармливает его вывод в фильтры .req.files и .prov.files (от
> идеи общего .files для .req и .prov пришлось отказаться).  Дальше
> фильтры выводят список файлов, и этот список файлов скармливается
> в .req или .prov.
> 
> Выглядит это вполне даже благовидно.

Даже очень.

[...]
> Кроме того, пакет git не собирается, потому что там в некоторых
> шелл-скриптах после `exit 0' идет некомментированный plain text.

Тогда почему до изменения пакет git собирается?

> Кроме того, будут проблемы с питоном, потому что `#!/usr/bin/env python'
> теперь отыскиваются слишком хорошо.

Что значит "слишком хорошо" и что значит "будут проблемы с питоном"?


-- 
ldv

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

Re: [devel] проблемы с поиском зависимостей [2]

[Michael Shigorin]

On Mon, Mar 12, 2007 at 03:36:30PM +0300, Alexey Tourbin wrote:
> Если в req/prov скриптах использовать опцию --verbose, то можно
> узнать что-нибудь интересное.
> $ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/shell.req.files |/usr/lib/rpm/shell.req -v 2>&1| head
> shell.req: /usr/bin/add_changelog: cat -> /bin/cat -> ... (via which)
> shell.req: /usr/bin/add_changelog: /bin/cat -> coreutils (via rpmdb)

Ой хорошо, сегодня только грепал recoll -- где ж он lyx зацепил.
Кстати, куда кто смотрит, что умудряется вытащить (правильную)
зависимость на отсутствующий в чруте пакет lyx-qt?

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

Re: [devel] проблемы с поиском зависимостей [2]

[Alexey Tourbin]

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

On Tue, Mar 13, 2007 at 12:49:52AM +0300, Dmitry V. Levin wrote:
> > Кроме того, пакет git не собирается, потому что там в некоторых
> > шелл-скриптах после `exit 0' идет некомментированный plain text.
> 
> Тогда почему до изменения пакет git собирается?

Речь идет о файле /usr/share/git-core/templates/hooks/pre-rebase.
Раньше зависимости искались только в исполняемых shell файлах,
а этот файл не исполняемый, и поэтому пакет собирался.

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

Кстати, например, в пакете service используется хак.
/etc/rc.d/init.d/functions находится в билдруте в исполняемом состоянии,
и поэтому зависимости в нём ищутся, а в cpio заворачивается уже в
неисполняемом состоянии через %attr.

Посмотрим на эту проблему с другой стороны: в чем в данном случае её
суть?  Суть в том, что обнаружились некие *настоящие* шелл-скрипты,
которые не проходят стандартной проверки `sh -n'.  С этой точки зрения
никакой специальной проблемы с поиском зависимостей как бы и нет.
Просто мы узнали то, на что раньше не обращали внимания.

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

А как решить эту проблему я подумаю, проще всего наверное будет добавить
проверку на ещё один частный случай в shell.req, наравне с exec в первой
строчке.

> > Кроме того, будут проблемы с питоном, потому что `#!/usr/bin/env python'
> > теперь отыскиваются слишком хорошо.
> 
> Что значит "слишком хорошо" и что значит "будут проблемы с питоном"?

Слишком хорошо означает что для #!/usr/bin/env python будет вызван
FindPackage "$f" /usr/bin/env python.

$ /usr/lib/rpm/shebang.req -v /usr/lib/rpm/python.req.py 
shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/env -> coreutils (via rpmdb)
coreutils
shebang.req: /usr/lib/rpm/python.req.py: python -> /usr/bin/python -> ... (via which)
shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/python -> python-strict (via rpmdb)
python-strict
$

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

У пакета rpm-build-python вообще никакой зависимости на python нету,
т.е. это такой дохляк, который прямо начиная с #! может не запуститься
и отвалить, а это противоречит нашему принципу что всё более-менее
должно работать из коробки без всяких там грубых посыланий и доустановок.

Хуже того, если я правильно понимаю, то скрипты из rpm-build-python
всячески скрывают свои зависимости, и если им чего-то не хватает, то они
отваливают абсолютно тихо, по-подлому.

python.req:
    35  try :
    36      import sys, os
    37      import parser, symbol, token, types
    38  except :
    39      pass    
    40  else :    

После else идет весь реальный код.  Такая же история с python.prov.py.
Т.е. мы можем не только недосчитаться requires зависимостей, но и
пропустить provides зависимости, а это уже чревато анметами в
репозитарии.  И, как известно, в репозитарии больше всего именно
питоновских анметов.  В общем, такой лажи быть не должно.

Резюмирую, что мне кажется рационально нужно сделать с питоном.

1) пересмотреть как питон распилен.  python-base должен давать работающий
/usr/bin/python и достаточно модулей для работы rpm-build-python.  Тогда
можно раскрыть зависимости в rpm-build-python и внести python-base в
базовую сборочную систему.

2) Изменить rpm-build-python чтобы если там чево-то отваливает то чтобы
хотя бы сообщал, что, мол, отваливаю, и чево не хватает.  А ещё лучше
чтобы просто отваливал, как следует.

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

Re: [devel] проблемы с поиском зависимостей [2]

[Alexey Tourbin]

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

On Tue, Mar 13, 2007 at 01:05:28AM +0200, Michael Shigorin wrote:
> On Mon, Mar 12, 2007 at 03:36:30PM +0300, Alexey Tourbin wrote:
> > Если в req/prov скриптах использовать опцию --verbose, то можно
> > узнать что-нибудь интересное.
> > $ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/shell.req.files |/usr/lib/rpm/shell.req -v 2>&1| head
> > shell.req: /usr/bin/add_changelog: cat -> /bin/cat -> ... (via which)
> > shell.req: /usr/bin/add_changelog: /bin/cat -> coreutils (via rpmdb)
> 
> Ой хорошо, сегодня только грепал recoll -- где ж он lyx зацепил.
> Кстати, куда кто смотрит, что умудряется вытащить (правильную)
> зависимость на отсутствующий в чруте пакет lyx-qt?

Если собирается хешером, то он смотрит в
$build/cache/contents/contents_index_bin.

Этот contents index как раз нужен чтобы лучше искать зависимости вопреки
минимальной сборочной среде и в ряде случаев давать более точные
зависимости, напр. зависимость на mutt должна разрешиться в
/usr/bin/mutt а не в mutt или mutt1.5, т.к. любой из них сгодится.

Кстати я внес много исправлений в find-package (это типа диспетчер как
искать такого рода зависимости), теперь в ряде "сложных" случаев
результат будет более корректным.  См. commit messages, там есть примеры
с /sbin/ifup, openssl-config, arpsend и vim.

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

[devel] [buildreq] Re: проблемы с поиском зависимостей [2]

[Michael Shigorin]

On Wed, Mar 14, 2007 at 01:32:01AM +0300, Alexey Tourbin wrote:
> > Кстати, куда кто смотрит, что умудряется вытащить (правильную)
> > зависимость на отсутствующий в чруте пакет lyx-qt?
> Если собирается хешером, то он смотрит в
> $build/cache/contents/contents_index_bin.

Так и подумал, но почему-то не поверилось. :)

PS: тут по buildreq вопрос возник.

Берём kino-0.9.5-alt4, добавляем тарбол 1.0.0, засовываем 
в hasher с такими BR в спеке:

# manually removed: imake
# Automatically added by buildreq on Sun Dec 24 2006
BuildRequires: gcc-c++ imake libalsa-devel libavc1394-devel libavformat-devel libdv-devel libfaac-devel libglade-devel libiec61883-devel liblame-devel libsamplerate-devel libSM-devel libXv-devel packages-info-i18n-common perl-XML-Parser xorg-cf-files
BuildRequires: liba52-devel

В чруте делаем buildreq, получаем такие:

# Automatically added by buildreq on Wed Mar 14 2007
BuildRequires: gcc-c++ imake libSM-devel libXv-devel libalsa-devel libavc1394-devel libdv-devel libglade-devel libiec61883-devel libsamplerate-devel packages-info-i18n-common xorg-cf-files

Разница:

# manually added (buildreq+hsh left these not installed):
BuildRequires: libavformat-devel libfaac-devel liblame-devel perl-XML-Parser liba52-devel

hsh-install этой разницы тащит весьма много
мультимедийно-сборочных пакетов, без которых
есть серьёзные сомнения (непроверенные) в 
пригодности сборки.

Тебе интересно этот вопрос совместно доковырять?
В смысле могу попробовать таки собраться с теми
(собирается, выпадает на изменениях по %files уже)
и проверить с камерой.

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

Re: [devel] проблемы с поиском зависимостей [2]

[Alexey Tourbin]

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

On Wed, Mar 14, 2007 at 11:42:46AM +0200, Michael Shigorin wrote:
> On Wed, Mar 14, 2007 at 01:32:01AM +0300, Alexey Tourbin wrote:
> > > Кстати, куда кто смотрит, что умудряется вытащить (правильную)
> > > зависимость на отсутствующий в чруте пакет lyx-qt?
> > Если собирается хешером, то он смотрит в
> > $build/cache/contents/contents_index_bin.
> 
> Так и подумал, но почему-то не поверилось. :)
> 
> PS: тут по buildreq вопрос возник.
> 
> Берём kino-0.9.5-alt4, добавляем тарбол 1.0.0, засовываем 
> в hasher с такими BR в спеке:
> 
> # manually removed: imake
> # Automatically added by buildreq on Sun Dec 24 2006
> BuildRequires: gcc-c++ imake libalsa-devel libavc1394-devel libavformat-devel libdv-devel libfaac-devel libglade-devel libiec61883-devel liblame-devel libsamplerate-devel libSM-devel libXv-devel packages-info-i18n-common perl-XML-Parser xorg-cf-files
> BuildRequires: liba52-devel
> 
> В чруте делаем buildreq, получаем такие:
> 
> # Automatically added by buildreq on Wed Mar 14 2007
> BuildRequires: gcc-c++ imake libSM-devel libXv-devel libalsa-devel libavc1394-devel libdv-devel libglade-devel libiec61883-devel libsamplerate-devel packages-info-i18n-common xorg-cf-files
> 
> Разница:
> 
> # manually added (buildreq+hsh left these not installed):
> BuildRequires: libavformat-devel libfaac-devel liblame-devel perl-XML-Parser liba52-devel

Возможно, в configure есть проверка на доступность дополнительных
библиотек, а XML::Parser находится где-то в eval.

> hsh-install этой разницы тащит весьма много
> мультимедийно-сборочных пакетов, без которых
> есть серьёзные сомнения (непроверенные) в 
> пригодности сборки.
> 
> Тебе интересно этот вопрос совместно доковырять?
> В смысле могу попробовать таки собраться с теми
> (собирается, выпадает на изменениях по %files уже)
> и проверить с камерой.

С камерой проверить не могу, остальное конечно интересно.

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

[devel] python problems

[Alexey Tourbin]

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

On Wed, Mar 14, 2007 at 01:12:39AM +0300, Alexey Tourbin wrote:
> > > Кроме того, будут проблемы с питоном, потому что `#!/usr/bin/env python'
> > > теперь отыскиваются слишком хорошо.
> > 
> > Что значит "слишком хорошо" и что значит "будут проблемы с питоном"?
> 
> Слишком хорошо означает что для #!/usr/bin/env python будет вызван
> FindPackage "$f" /usr/bin/env python.
> 
> $ /usr/lib/rpm/shebang.req -v /usr/lib/rpm/python.req.py 
> shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/env -> coreutils (via rpmdb)
> coreutils
> shebang.req: /usr/lib/rpm/python.req.py: python -> /usr/bin/python -> ... (via which)
> shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/python -> python-strict (via rpmdb)
> python-strict
> $
> 
> А пакет python-strict, грубо говоря, требует все остальные пакеты, на
> которые распилен питон.  Последнее явно неприемлемо для базовой
> сборочной системы (тогда как внесение python-base в базовую систему
> кажется мне приемлемым).
> 
> У пакета rpm-build-python вообще никакой зависимости на python нету,
> т.е. это такой дохляк, который прямо начиная с #! может не запуститься
> и отвалить, а это противоречит нашему принципу что всё более-менее
> должно работать из коробки без всяких там грубых посыланий и доустановок.
> 
> Хуже того, если я правильно понимаю, то скрипты из rpm-build-python
> всячески скрывают свои зависимости, и если им чего-то не хватает, то они
> отваливают абсолютно тихо, по-подлому.
> 
> python.req:
>     35  try :
>     36      import sys, os
>     37      import parser, symbol, token, types
>     38  except :
>     39      pass    
>     40  else :    
> 
> После else идет весь реальный код.  Такая же история с python.prov.py.
> Т.е. мы можем не только недосчитаться requires зависимостей, но и
> пропустить provides зависимости, а это уже чревато анметами в
> репозитарии.  И, как известно, в репозитарии больше всего именно
> питоновских анметов.  В общем, такой лажи быть не должно.
> 
> Резюмирую, что мне кажется рационально нужно сделать с питоном.
> 
> 1) пересмотреть как питон распилен.  python-base должен давать работающий
> /usr/bin/python и достаточно модулей для работы rpm-build-python.  Тогда
> можно раскрыть зависимости в rpm-build-python и внести python-base в
> базовую сборочную систему.
> 
> 2) Изменить rpm-build-python чтобы если там чево-то отваливает то чтобы
> хотя бы сообщал, что, мол, отваливаю, и чево не хватает.  А ещё лучше
> чтобы просто отваливал, как следует.

Ну что, специалисты по питону есть, или мне придется взять быка за рога?

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

Re: [devel] python problems

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070314 13:14]:
> Ну что, специалисты по питону есть, или мне придется взять быка
> за рога?
Ой, возьми!!!

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] python problems

[Alexey Tourbin]

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

On Wed, Mar 14, 2007 at 01:34:07PM +0300, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070314 13:14]:
> > Ну что, специалисты по питону есть, или мне придется взять быка
> > за рога?
> Ой, возьми!!!

Ой, начал ковырять, ничего не понимаю.

$ /usr/lib/rpm/python.req.py /usr/bin/asciidoc
$ /usr/lib/rpm/python.req.py <<< /usr/bin/asciidoc
$ grep -w import /usr/bin/asciidoc
import sys, os, re, string, time, traceback, tempfile, popen2, codecs
from types import *
from UserDict import UserDict
        import select
        import StringIO
        import csv
    import getopt
        import profile
$

Что называется, ни ответа ни привета.
Не могу отказать Андрею Орлову в профессионализме, но что-то здесь не так.

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

Re: [devel] python problems

[Alexey Tourbin]

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

On Wed, Mar 14, 2007 at 01:42:25PM +0300, Alexey Tourbin wrote:
> > > Ну что, специалисты по питону есть, или мне придется взять быка
> > > за рога?
> > Ой, возьми!!!
> 
> Ой, начал ковырять, ничего не понимаю.
> 
> $ /usr/lib/rpm/python.req.py /usr/bin/asciidoc
> $ /usr/lib/rpm/python.req.py <<< /usr/bin/asciidoc

К концу дня:

$ /usr/lib/rpm/python.req.py /usr/bin/asciidoc 
python2.4(os)
python2.4(re)
python2.4(string)
python2.4(time)
python2.4(traceback)
python2.4(tempfile)
python2.4(popen2)
python2.4(codecs)
python2.4(types)
python2.4(UserDict)
$

Not that bad.

> $ grep -w import /usr/bin/asciidoc
> import sys, os, re, string, time, traceback, tempfile, popen2, codecs
> from types import *
> from UserDict import UserDict
>         import select
>         import StringIO
>         import csv
>     import getopt
>         import profile
> $

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

Re: [devel] проблемы с поиском зависимостей [2]

[Ivan Fedorov]

Alexey Tourbin пишет:
> On Tue, Mar 13, 2007 at 12:49:52AM +0300, Dmitry V. Levin wrote:
>>> Кроме того, будут проблемы с питоном, потому что `#!/usr/bin/env python'
>>> теперь отыскиваются слишком хорошо.
>> Что значит "слишком хорошо" и что значит "будут проблемы с питоном"?
> 
> Слишком хорошо означает что для #!/usr/bin/env python будет вызван
> FindPackage "$f" /usr/bin/env python.
> 
> $ /usr/lib/rpm/shebang.req -v /usr/lib/rpm/python.req.py 
> shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/env -> coreutils (via rpmdb)
> coreutils
> shebang.req: /usr/lib/rpm/python.req.py: python -> /usr/bin/python -> ... (via which)
> shebang.req: /usr/lib/rpm/python.req.py: /usr/bin/python -> python-strict (via rpmdb)
> python-strict
> $
А потому что нехер требовать /usr/bin/python. Надо требовать 
/usr/bin/pythonX.Y!

> А пакет python-strict, грубо говоря, требует все остальные пакеты, на
> которые распилен питон.
Да. Это такой специальный пакет, для тех кто хочет, чтобы было "как из 
тарбола".
>  Последнее явно неприемлемо для базовой
> сборочной системы (тогда как внесение python-base в базовую систему
> кажется мне приемлемым).
А вот в прошлый раз мне сказали, что в базовой среде уже и так есть perl 
и тащить туда python не надо!

> У пакета rpm-build-python вообще никакой зависимости на python нету,
Да... когда я хотел ее прикрутить, все громко ругались матом.
> т.е. это такой дохляк, который прямо начиная с #! может не запуститься
> и отвалить, а это противоречит нашему принципу что всё более-менее
> должно работать из коробки без всяких там грубых посыланий и доустановок.
Сложно заставить работать python-модуль без python!

> Хуже того, если я правильно понимаю, то скрипты из rpm-build-python
> всячески скрывают свои зависимости, и если им чего-то не хватает, то они
> отваливают абсолютно тихо, по-подлому.
Да.

> Резюмирую, что мне кажется рационально нужно сделать с питоном.
> 
> 1) пересмотреть как питон распилен.  python-base должен давать работающий
> /usr/bin/python и достаточно модулей для работы rpm-build-python.  Тогда
> можно раскрыть зависимости в rpm-build-python и внести python-base в
> базовую сборочную систему.
rpm-build-python должен зависеть от devel части!
> 
> 2) Изменить rpm-build-python чтобы если там чево-то отваливает то чтобы
> хотя бы сообщал, что, мол, отваливаю, и чево не хватает.  А ещё лучше
> чтобы просто отваливал, как следует.
Ну не прошло и века...

Re: [devel] проблемы с поиском зависимостей [2]

[Alexey I. Froloff]

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

* Ivan Fedorov <ns_alt_devel@> [070315 13:07]:
> А потому что нехер требовать /usr/bin/python. Надо требовать 
> /usr/bin/pythonX.Y!
А нехер(tm) изобретать /usr/bin/pythonX.Y там где хватает
/usr/bin/python.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] проблемы с поиском зависимостей [2]

[Aleksey Avdeev]

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

Alexey I. Froloff пишет:
> * Ivan Fedorov <ns_alt_devel@> [070315 13:07]:
> 
>>А потому что нехер требовать /usr/bin/python. Надо требовать 
>>/usr/bin/pythonX.Y!
> 
> А нехер(tm) изобретать /usr/bin/pythonX.Y там где хватает
> /usr/bin/python.

  Насколько помню, /usr/bin/pythonX.Y не без причин появился...

  Как предлагаете разрешать ситуацию, когда программа A работает только
с pythonX.Y, но не с pythonX.Z, а B наоборот, если A и B необходимы
одновременно?

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

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] проблемы с поиском зависимостей [2]

[Ivan Fedorov]

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

Alexey I. Froloff пишет:
> * Ivan Fedorov <ns_alt_devel@> [070315 13:07]:
>> А потому что нехер требовать /usr/bin/python. Надо требовать 
>> /usr/bin/pythonX.Y!
> А нехер(tm) изобретать /usr/bin/pythonX.Y там где хватает
> /usr/bin/python.

Ну вообще-то изначально несколько питонов просили!!!


Мне например обычно хватает квалификации переписать код под новый питон.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] проблемы с поиском зависимостей [2]

[Igor Vlasenko]

On Thu, Mar 15, 2007 at 01:27:58PM +0300, Alexey I. Froloff wrote:
> * Ivan Fedorov <ns_alt_devel@> [070315 13:07]:
> > А потому что нехер требовать /usr/bin/python. Надо требовать 
> > /usr/bin/pythonX.Y!
> А нехер(tm) изобретать /usr/bin/pythonX.Y там где хватает
> /usr/bin/python.

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

-- 

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

Re: [devel] проблемы с поиском зависимостей [2]

[Alexey I. Froloff]

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

* Aleksey Avdeev <solo@> [070315 13:57]:
>   Как предлагаете разрешать ситуацию, когда программа A работает только
> с pythonX.Y, но не с pythonX.Z, а B наоборот, если A и B необходимы
> одновременно?
А никак она не разрешится.  У нас питоньи модули собраны в одном
экземпляре.  Ещё Великий Cray говорил, что у нас один питон, на
что я спрашивал, почему тогда у нас их два, и не получал ответа.

А программу такую я знаю ровно одну - Zope.  И в Сизифе она
практически померла.  Потому как на каждую сборку Zope надо
вешать табличку "номально работает в Master X.Y/Сизифе от
YYYY.MM.DD".

P.S. Я до сих пор помню переезд с 2.3 на 2.4.  Повторения не
хочется.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] проблемы с поиском зависимостей [2]

[Alexey I. Froloff]

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

* Ivan Fedorov <ns_alt_devel@> [070315 14:02]:
> >> А потому что нехер требовать /usr/bin/python. Надо требовать 
> >> /usr/bin/pythonX.Y!
> > А нехер(tm) изобретать /usr/bin/pythonX.Y там где хватает
> > /usr/bin/python.
> Ну вообще-то изначально несколько питонов просили!!!
Да никто не просил.  Zope не работала, вот и всё.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] проблемы с поиском зависимостей [2]

[Ivan Fedorov]

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

Igor Vlasenko пишет:
> On Thu, Mar 15, 2007 at 01:27:58PM +0300, Alexey I. Froloff wrote:
>> * Ivan Fedorov <ns_alt_devel@> [070315 13:07]:
>>> А потому что нехер требовать /usr/bin/python. Надо требовать 
>>> /usr/bin/pythonX.Y!
>> А нехер(tm) изобретать /usr/bin/pythonX.Y там где хватает
>> /usr/bin/python.
> 
> А модераторы в этой рассылке есть?
> Такие письма - это не только неуважение писателя к самому себе,
> но и к читателям ...
> 
Есть... ldv@...

PS: Да идет вся эта рассылка куда подальше... тут сильно много сильно
умных "проституток"...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[devel] [JT] Re: проблемы с поиском зависимостей [2]

[Igor Vlasenko]

On Thu, Mar 15, 2007 at 07:40:21PM +0800, Ivan Fedorov wrote:
> > А модераторы в этой рассылке есть?
> Есть... ldv@...

Попросим Диму тушить такие дискуссии...
Очень плохо будет, и всем, если потеряем уважение...

в тему с ЛОРа цитата
---------------------------------------------
Основатель Gentoo вернулся и ... снова ушёл

Daniel Robbins - человек, который основал дистрибутив Gentoo в 2000 году, являясь его главным архитектором, после своего ухода в 2004 году недавно сделал попытку вернуться в команду разработчиков. Однако ничего не получилось - после персональных нападок в свой адрес со стороны других разработчиков он снова ушёл.

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

Update: Покинув core-team Даниэль остался в amd64-team
http://distrowatch.com/weekly.php?issue=20070312#future
---------------------------------------------

-- 

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

Re: [devel] проблемы с поиском зависимостей [2]

[Alexey Tourbin]

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

On Thu, Mar 15, 2007 at 07:40:21PM +0800, Ivan Fedorov wrote:
> PS: Да идет вся эта рассылка куда подальше... тут сильно много сильно
> умных "проституток"...

Не кипятитесь.  Помните о конструктивности.  Если Вам есть что сказать
и если Вы чувствуете, что правы, значит, проститутки Вам не страшны.

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

[devel] Administrativia

[Dmitry V. Levin]

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

On Thu, Mar 15, 2007 at 06:07:10PM +0800, Ivan Fedorov wrote:
[...]
> А потому что нехер требовать [...]

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


-- 
ldv

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

Re: [devel] [JT] Re: проблемы с поиском зависимостей [2]

[Ivan Fedorov]

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

Igor Vlasenko пишет:
> On Thu, Mar 15, 2007 at 07:40:21PM +0800, Ivan Fedorov wrote:
>>> А модераторы в этой рассылке есть?
>> Есть... ldv@...
> 
> Попросим Диму тушить такие дискуссии...
Он услышал вашу просьбу!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] проблемы с поиском зависимостей [2]

[Денис Смирнов]

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

On Thu, Mar 15, 2007 at 06:07:10PM +0800, Ivan Fedorov wrote:

>>  Последнее явно неприемлемо для базовой
>> сборочной системы (тогда как внесение python-base в базовую систему
>> кажется мне приемлемым).
IF> А вот в прошлый раз мне сказали, что в базовой среде уже и так есть perl 
IF> и тащить туда python не надо!

Рассказываю тебе страшную тайну. Когда человек мне говорит "а хрен ли у
тебя сделано вот так, а не вот-так?" и я с ним не согласен я отвечаю
просто -- "давай ссылку на свой git-repo где сделано так как ты хочешь, но
при этом не имеет негативных side-effects по сравнению с моим решением".

Если человек не может меня мотивировать к внесению какого-то изменения он
его делает сам и дает мне сделать pull из своего репо. И если изменения
мне понравятся, я их втяну.

>> У пакета rpm-build-python вообще никакой зависимости на python нету,
IF> Да... когда я хотел ее прикрутить, все громко ругались матом.

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

>> 2) Изменить rpm-build-python чтобы если там чево-то отваливает то чтобы
>> хотя бы сообщал, что, мол, отваливаю, и чево не хватает.  А ещё лучше
>> чтобы просто отваливал, как следует.
IF> Ну не прошло и века...

Опыт показывает что чтобы ты не делал все это обматерят. И единицы скажут
спасибо. Так вот, именно поэтому когда я взялся за asterisk, то мой
seirospbx работает так, как _мне_ нравится. Тех кому не нравится я посылаю
нафиг (с конкретным указанием альтернатив которые мне известны, вроде
всяких Asterisk@Home), или предлагать улучшения.

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

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

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

Ты уж определись что тебе важнее -- мнение других, или твой опыт.

А материться все горазды. Я вон инсталлер наш материть не устаю. Однако
при этом я уважаю тех кто над ним работает, и благодарен за их работу. Но
то что мне в нем не нравится критиковать все равно буду. А уж авторы
разберутся где к критике прислушаться, где в /dev/null отправить.

Не стоит воспринимать обсуждения в девелоперских мейллистах эмоционально.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Настоящий программист - это тот, кто умеет писать программы, но не делает этого.


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