[devel] I: Утилита buildreq-src

[devel] I: Утилита buildreq-src

[Igor Vlasenko]

Утилита buildreq-src
____________________

Утилита живет сейчас в пакете perl-RPM-Source-Dependency-Analyzer.
Однако так как ранее она уже кочевала из пакета в пакет,
ее лучше устанавливать как
apt-get install /usr/bin/buildreq-src

Утилиту можно использовать как при создании пакета,
так и при сопровождении пакета.

Создание пакета.
_______________

При создании пакета у нас есть только исходники.
Их и передадим утилите.

Это может быть 

* архив исходников
buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz

* каталог с распакованными исходниками
buildreq-src ../BUILD/lbreakout2-2.6.5

* или даже отдельные файлы:
buildreq-src ../BUILD/lbreakout2-2.6.5/configure.ac

Запустим, к примеру, buildreq-src с архивом исходников.

$ buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz

утилита выведет найденные сборочные зависимости:

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel libpng-devel zlib-devel
# END SourceDeps(oneline)

Их можно вручную вставить в spec файл.
Однако утилита и сама может сделать это, если ей дать еще и spec файл.

Сопровождение пакета.
_____________________

Утилита buildreq-src не работает напрямую c src.rpm пакетом.
его надо сначала установить:
rpm -i ../SRPMS/lbreakout2-2.6.5-alt1.src.rpm
В gear git репозитории обычно уже ничего делать не нужно,
и спек файл, и каталог с распакованными исходниками уже 
под рукой.

Опять запустим buildreq-src, дополнительно передав 
ей spec файл опцией --spec <путь>.
С опцией --spec buildreq-src только прочитает spec файл.
Никаких изменений в spec файле не произойдет.

buildreq-src --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz 

На этот раз утилита выведет более короткий список:

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)

Этот список -- разность между сборочными зависимостями
пакета lbreakout2, найденными утилитой buildreq-src,
и сборочными зависимостями пакета, прописанными в его
спек файле.

Список не пустой --- buildreq-src для lbreakout2
нашла две зависимости для lbreakout2, которые не
указаны в спек файле: libSDL_net-devel и zlib-devel.

Отсутствие zlib-devel не имело последствий, так как
в итоге lbreakout2 все равно слинковался с -lz.
Ее в итоге вытянула какая-то из других зависимостей.
Однако поскольку lbreakout2 явно линкуется с zlib,
то zlib-devel лучше добавить в BuildRequires явно.
Сегодня она неявно вытягивается по зависимостям, 
а завтра может и не вытянуться. Тогда сборка сломается,
или, что еще хуже, пакет молча соберется но потеряет
часть функциональности -- не сможет работать 
со сжатыми данными.

С libSDL_net-devel проблема немножко серьезнее.
lbreakout2 собирается и без libSDL_net-devel,
но у lbreakout2 есть режим сетевой игры.
для которого libSDL_net-devel и нужен.

Эту ситуацию я называю недособранным пакетом.
В 99% случаев имеющейся функциональности lbreakout2 достаточно,
но если вдруг пришли бы к ребенку гости и дети захотели бы 
попробовать по сети сыграть, то --enable-network
был бы кстати.

buildreq-src -bp
________________

Имеющиеся патчи могут существенно изменить пакет,
в частности, поменять его сборочные зависимости.
Поэтому имеет смысл запускать утилиту уже на 
правленные исходники. Для удобства, в 
buildreq-src есть опция -bp, которая как раз это 
и делает: вызывает rpmbuild -bp <name>.spec,
затем напускает buildreq-src на %builddir.

$ buildreq-src -bp lbreakout2.spec
Выполняется(%prep): /bin/sh -e /tmp/rpm-tmp.83798
+ umask 022
+ /bin/mkdir -p /home/RPM/BUILD
+ cd /home/RPM/BUILD
+ cd /home/RPM/BUILD
+ rm -rf lbreakout2-2.6.5
+ echo 'Source #0 (lbreakout2-2.6.5.tar):'
Source #0 (lbreakout2-2.6.5.tar):
+ /bin/tar -xf -
+ cd lbreakout2-2.6.5
+ /bin/chmod -c -Rf u+rwX,go-w .
+ exit 0
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)


Секция BEGIN/END SourceDeps
___________________________

Если все найденные зависимости уже есть в spec файле,
buildreq-src выдаст сообщение 

buildreq-src: c2050.spec already contains all found dependencies

если каких-то зависимостей нет, то они будут выведены в виде

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)

здесь "# BEGIN SourceDeps(oneline):" и "# END SourceDeps(oneline)" --
волшебные комментарии.

BuildRequires: libSDL_net-devel zlib-devel, 
которые нашла buildreq-src, можно вставить 
в lbreakout2.spec руками. Однако если добавить 
опцию --update (примеры вызова:)

buildreq-src --update --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz 
buildreq-src --update -bp lbreakout2.spec

то buildreq-src вставит в lbreakout2.spec фрагмент
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)
как раз в окружении волшебных комментариев.

Эти комментарии очень важны: они позволяют организовать
полуавтоматическое обновление сборочных зависимостей пакета.

Работает оно следующим образом: без опции --update
buildreq-src вообще не трогает пакет. С опцией --update
buildreq-src правит только то, что находится между
# BEGIN SourceDeps(oneline): 
и 
# END SourceDeps(oneline)
Все, что вне, считается неприкосновенным.

Как это работает: пусть у нас в lbreakout2.spec вручную вписано

BuildRequires: libSDL-devel libSDL_mixer-devel
BuildRequires: libpng-devel zlib-devel

и в новой версии lbreakout2 переехал на libSDL2.
Вызовем buildreq-src --update ...
утилита вставит в спек новые найденные зависимости
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)
но старые устаревшие 
BuildRequires: libSDL-devel libSDL_mixer-devel
останутся, так как они внесены вручную, а майнтайнер всегда прав.

Если же в спеке было
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel
# END SourceDeps(oneline)
то после вызова buildreq-src --update ...
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)
т.е. новые автонайденные зависимости перезапишут собой старые
автонайденные зависимости и старые устаревшие зависимости
libSDL-devel libSDL_mixer-devel удалятся из спека.

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

Формат найденных зависимостей.
______________________________
По умолчанию,  buildreq-src там, где можно, пытается вывести найденные
зависимости в пакетнонезависимом формате, так, как они упоминаются в тексте:

# BEGIN SourceDeps(oneline):
BuildRequires: /usr/bin/glib-gettextize perl(GD/Text/Wrap.pm) pkgconfig(cairo)
# END SourceDeps(oneline)
Это поведение можно изменить, указав  
 --sourcedep-resolve=all
или, что то же самое
 --sourcedep-resolve=path,perl,pkgconfig
получим более привычные
# BEGIN SourceDeps(oneline):
BuildRequires: glib2-devel perl-GD-Text libcairo-devel
# END SourceDeps(oneline)


В следующем письме алгоритм работы утилиты,
известные баги и фичи. Содержание:

в силу самого своего алгоритма 
buildreq-src сожет зачерпнуть (и зачерпывает) и реально не нужные,
лишние зависимости. Как их распознать и как с этим бороться.
Как помочь утилите, когда она не справляется.
Продолжение следует.



-- 

I V

Re: [devel] I: Утилита buildreq-src

[Andrey Cherepanov]

14.03.2016 19:40, Igor Vlasenko пишет:
> в силу самого своего алгоритма 
> buildreq-src сожет зачерпнуть (и зачерпывает) и реально не нужные,
> лишние зависимости. Как их распознать и как с этим бороться.
> Как помочь утилите, когда она не справляется.
> Продолжение следует.
Игорь, эвристика работы утилиты требует наличия установленных
потенциальных пакетов -devel?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Tue, Mar 15, 2016 at 10:23:11AM +0300, Andrey Cherepanov wrote:
> 14.03.2016 19:40, Igor Vlasenko пишет:
> > в силу самого своего алгоритма 
> > buildreq-src сожет зачерпнуть (и зачерпывает) и реально не нужные,
> > лишние зависимости. Как их распознать и как с этим бороться.
> > Как помочь утилите, когда она не справляется.
> > Продолжение следует.
> Игорь, эвристика работы утилиты требует наличия установленных
> потенциальных пакетов -devel?

Нет, не требует.
buildreq-src нужен, когда мы не знаем, чего устанавливать.

Если мы уже знаем и установили все потенциальные пакеты -devel,
то уже актуальна вторая задача - убрать лишнее,
для чего есть /usr/bin/buildreq из rpm-utils от at@.


-- 

I V

Re: [devel] I: Утилита buildreq-src

[Hihin Ruslan]

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

Здравствуйте Igor Vlasenko
  В сообщении от 15 марта 2016 Igor Vlasenko написал(a):
> On Tue, Mar 15, 2016 at 10:23:11AM +0300, Andrey Cherepanov 
wrote:
> > 14.03.2016 19:40, Igor Vlasenko пишет:
> > > в силу самого своего алгоритма
> > > buildreq-src сожет зачерпнуть (и зачерпывает) и реально не
> > > нужные, лишние зависимости. Как их распознать и как с этим
> > > бороться. Как помочь утилите, когда она не справляется.
> > > Продолжение следует.
> >
> > Игорь, эвристика работы утилиты требует наличия
> > установленных потенциальных пакетов -devel?
>
> Нет, не требует.
> buildreq-src нужен, когда мы не знаем, чего устанавливать.
>
> Если мы уже знаем и установили все потенциальные пакеты
> -devel, то уже актуальна вторая задача - убрать лишнее,
> для чего есть /usr/bin/buildreq из rpm-utils от at@.

Спасибо за ваш инструмент. Попробовал на palemoon:

BuildRequires: libssl-devel perl(Archive/Zip.pm) perl(CGI.pm) 
perl(CGI/Carp.pm) perl(Carp.pm) perl(DBI.pm) perl(Errno.pm) 
..............
perl(base.pm) perl(diagnostics.pm) perl(strict.pm) perl(subs.pm) 
python-devel texinfo


Вызвало сомнение - неужели нужны все эти перловые модули. Обычный 
buildreq этих зависимостей не нашёл (хотя все они были в хешере 
установлены).

-- 
  А ещё говорят так  (fortune):
 
 .

________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] I: Утилита buildreq-src

[Anton V. Boyarshinov]

> perl(base.pm) perl(diagnostics.pm) perl(strict.pm) perl(subs.pm) 

> 
> Вызвало сомнение - неужели нужны все эти перловые модули. Обычный 
> buildreq этих зависимостей не нашёл (хотя все они были в хешере 
> установлены).
Насколько я понимаю по этому выводу, buildreq-src просто не фильтрует
вывод и не удаляет из него то, что вытягивается другими пакетами или
входит в них. Так, например, все перловые модули из процитированного
мной, очевидно, входят в perl-base.

Насколько я понимаю, "очистить" список от излишнего можно при помощи
buildreq.

Re: [devel] I: Утилита buildreq-src

[Sergey V Turchin]

On Wednesday, 16 March 2016 10:55:58 MSK Anton V wrote:

[...]
> Насколько я понимаю, "очистить" список от излишнего можно при помощи
> buildreq.
Полезность buildreq-src получается сомнительная, т.к. мне, например, обычно 
хочется, чтобы кто-то умел чистить то, что делает buildreq. А в том, что 
базово необходимо для сборки, у меня проблем никогда не возникало.

P.S.
Почти во всех своих пакетах я оставляю комментарием результат buildreq, чтобы 
можно было сравнить с реальностью.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: Утилита buildreq-src

[Sergey V Turchin]

On Wednesday, 16 March 2016 11:10:01 MSK Sergey V wrote:
> On Wednesday, 16 March 2016 10:55:58 MSK Anton V wrote:
> 
> [...]
> 
> > Насколько я понимаю, "очистить" список от излишнего можно при помощи
> > buildreq.
> 
> Полезность buildreq-src получается сомнительная
Разве что, для автомата, который будет после нее использовать buildreq.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: Утилита buildreq-src

[Anton Farygin]

On 16.03.2016 11:18, Sergey V Turchin wrote:
> On Wednesday, 16 March 2016 11:10:01 MSK Sergey V wrote:
>> On Wednesday, 16 March 2016 10:55:58 MSK Anton V wrote:
>>
>> [...]
>>
>>> Насколько я понимаю, "очистить" список от излишнего можно при помощи
>>> buildreq.
>>
>> Полезность buildreq-src получается сомнительная
> Разве что, для автомата, который будет после нее использовать buildreq.
>
> [...]
>

buildreq-src нужен для того, что бы не устанавливать все devel пакеты 
себе в хост-систему.

т.е. - выполняешь buildreq-src, полученный хлам используешь в 
hsh-initroot и уже там запускаешь buildreq.

Re: [devel] I: Утилита buildreq-src

[Sergey V Turchin]

On Wednesday, 16 March 2016 11:21:12 MSK Anton Farygin wrote:

[...]
> buildreq-src нужен для того, что бы не устанавливать все devel пакеты
> себе в хост-систему.
> 
> т.е. - выполняешь buildreq-src, полученный хлам используешь в
> hsh-initroot и уже там запускаешь buildreq.
kde5-* она, похоже, не осилит.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 01:17:25PM +0300, Sergey V Turchin wrote:
> On Wednesday, 16 March 2016 11:21:12 MSK Anton Farygin wrote:
> 
> [...]
> > buildreq-src нужен для того, что бы не устанавливать все devel пакеты
> > себе в хост-систему.
> > 
> > т.е. - выполняешь buildreq-src, полученный хлам используешь в
> > hsh-initroot и уже там запускаешь buildreq.
> kde5-* она, похоже, не осилит.

Осилить могла бы, она просто не настроена нормально для
kde4/kf5. Так исторически сложилось, что я писал 
библиотеку для нужд импорта пакетов.

А так как вы хороший майнтайнер, то вы все в Сизиф собрали сами,
соответственно, для autoimports kde4/kf5 пакетов осталось мало,
и мне не осталось кошек, на каких бы я тренировал библиотеку :(

Я если что тогда буду спрашивать.


-- 

I V

Re: [devel] I: Утилита buildreq-src

[Sergey V Turchin]

On Wednesday, 16 March 2016 12:27:19 MSK Igor Vlasenko wrote:
> On Wed, Mar 16, 2016 at 01:17:25PM +0300, Sergey V Turchin wrote:
> > On Wednesday, 16 March 2016 11:21:12 MSK Anton Farygin wrote:
> > 
> > [...]
> > 
> > > buildreq-src нужен для того, что бы не устанавливать все devel пакеты
> > > себе в хост-систему.
> > > 
> > > т.е. - выполняешь buildreq-src, полученный хлам используешь в
> > > hsh-initroot и уже там запускаешь buildreq.
> > 
> > kde5-* она, похоже, не осилит.
> 
> Осилить могла бы, она просто не настроена нормально для
> kde4/kf5. Так исторически сложилось, что я писал
> библиотеку для нужд импорта пакетов.
> 
> А так как вы хороший майнтайнер, то вы все в Сизиф собрали сами,
> соответственно, для autoimports kde4/kf5 пакетов осталось мало,
> и мне не осталось кошек, на каких бы я тренировал библиотеку :(
На существующих разве нельзя?

> Я если что тогда буду спрашивать.
Ok.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 01:36:55PM +0300, Sergey V Turchin wrote:
> > Осилить могла бы, она просто не настроена нормально для
> > kde4/kf5. Так исторически сложилось, что я писал
> > библиотеку для нужд импорта пакетов.
> > 
> > А так как вы хороший майнтайнер, то вы все в Сизиф собрали сами,
> > соответственно, для autoimports kde4/kf5 пакетов осталось мало,
> > и мне не осталось кошек, на каких бы я тренировал библиотеку :(
> На существующих разве нельзя?

Будь у меня тысяча рук...
Только недавно добавил на троечку работающую
поддержку CMake.
а поддержки python еще совсем нет...

-- 

I V

Re: [devel] I: Утилита buildreq-src

[Sergey V Turchin]

On Wednesday, 16 March 2016 12:40:09 MSK Igor Vlasenko wrote:

[...]
> Только недавно добавил на троечку работающую
> поддержку CMake.
Я об этом и пришёл.
Там зависимости вида
find_package(KF5 "${KF5_DEP_VERSION}" COMPONENTS
  Activities
  DocTools
)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[devel] Утилита buildreq-src и KF5

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 01:53:16PM +0300, Sergey V Turchin wrote:
> On Wednesday, 16 March 2016 12:40:09 MSK Igor Vlasenko wrote:
> 
> [...]
> > Только недавно добавил на троечку работающую
> > поддержку CMake.
> Я об этом и пришёл.
> Там зависимости вида
> find_package(KF5 "${KF5_DEP_VERSION}" COMPONENTS
>   Activities
>   DocTools
> )

Отправил perl-RPM-Source-Dependency-Analyzer-0.029-alt1.src.rpm

там есть поддержка COMPONENTS в find_package
но еще нет поддержки KF5. К примеру,
$ buildreq-src baloo-5.19.0.tar
info: CMAKE: find_package(KF5::CoreAddons) not added to SourceAnalyzer db, skipped
# BEGIN SourceDeps(oneline):
BuildRequires: /usr/bin/ecm gcc-c++ liblmdb-devel qt5-base-devel qt5-declarative-devel
# END SourceDeps(oneline)

Теперь мне надо список компонент KF5 -
я вроде бы нашел 
/usr/share/ECM/find-modules/FindKF5.cmake    extra-cmake-modules
но не понял, как определить, какие в KF5 есть компоненты.

Сергей, нуждаюсь в твоем совете.


-- 

I V

Re: [devel] Утилита buildreq-src и KF5

[Sergey V Turchin]

On Thursday, 17 March 2016 00:01:35 MSK Igor Vlasenko wrote:
> On Wed, Mar 16, 2016 at 01:53:16PM +0300, Sergey V Turchin wrote:
> > On Wednesday, 16 March 2016 12:40:09 MSK Igor Vlasenko wrote:
> > 
> > [...]
> > 
> > > Только недавно добавил на троечку работающую
> > > поддержку CMake.
> > 
> > Я об этом и пришёл.
> > Там зависимости вида
> > find_package(KF5 "${KF5_DEP_VERSION}" COMPONENTS
> > 
> >   Activities
> >   DocTools
> > 
> > )
> 
> Отправил perl-RPM-Source-Dependency-Analyzer-0.029-alt1.src.rpm
> 
> там есть поддержка COMPONENTS в find_package
> но еще нет поддержки KF5. К примеру,
> $ buildreq-src baloo-5.19.0.tar
> info: CMAKE: find_package(KF5::CoreAddons) not added to SourceAnalyzer db,
> skipped # BEGIN SourceDeps(oneline):
> BuildRequires:
> /usr/bin/ecm
Лишний, если что.

> gcc-c++ liblmdb-devel qt5-base-devel
> qt5-declarative-devel # END SourceDeps(oneline)
> 
> Теперь мне надо список компонент KF5 -
> я вроде бы нашел
> /usr/share/ECM/find-modules/FindKF5.cmake    extra-cmake-modules
Он тоже должен попадать в сборочные зависимости.

> но не понял, как определить, какие в KF5 есть компоненты.
По имени каталога %_libdir/cmake/KF5*

> Сергей, нуждаюсь в твоем совете.
Они в extra-cmake-modules так на...вертили скрипты, что я зачастую с трудом 
понимаю. :-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] Утилита buildreq-src и KF5

[Igor Vlasenko]

On Thu, Mar 17, 2016 at 11:13:23AM +0300, Sergey V Turchin wrote:
> > /usr/bin/ecm
> Лишний, если что.

Спасибо, поправил. Будет в 0.30
 
> > но не понял, как определить, какие в KF5 есть компоненты.
> По имени каталога %_libdir/cmake/KF5*

Ок, понял. я тогда универсальную систему напишу -
repocop будет собирать базу внешних к CMake devel пакетов, 
которые таскают с собой cmake файлы.

Тогда легко резолвить:
пробили по базе find_package(KF5 COMPONENTS XmlRpcClient)
выпало
/usr/lib64/cmake/KF5XmlRpcClient  -> kf5-kxmlrpcclient-devel

Это, наверное, уже в 0.31

-- 

I V

Re: [devel] Утилита buildreq-src и KF5

[Sergey V Turchin]

On Thursday, 17 March 2016 12:28:04 MSK Igor Vlasenko wrote:
> On Thu, Mar 17, 2016 at 11:13:23AM +0300, Sergey V Turchin wrote:
> > > /usr/bin/ecm
> > 
> > Лишний, если что.
> 
> Спасибо, поправил. Будет в 0.30
> 
> > > но не понял, как определить, какие в KF5 есть компоненты.
> > 
> > По имени каталога %_libdir/cmake/KF5*
> 
> Ок, понял. я тогда универсальную систему напишу -
> repocop будет собирать базу внешних к CMake devel пакетов,
> которые таскают с собой cmake файлы.
> 
> Тогда легко резолвить:
> пробили по базе find_package(KF5 COMPONENTS XmlRpcClient)
> выпало
> /usr/lib64/cmake/KF5XmlRpcClient  -> kf5-kxmlrpcclient-devel
Да.

Еще я замечал ругань cmake при ненахождении компонента про то, что в нижнем 
регистре тоже может лежать на диске.
Ругань типа:
Could not find a package configuration file with any of the following names:
  KF5XmlRpcClientConfig.cmake
  kf5xmlrpcclient-config.cmake

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

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 11:21:12AM +0300, Anton Farygin wrote:
> buildreq-src нужен для того, что бы не устанавливать все devel пакеты себе в
> хост-систему.
> 
> т.е. - выполняешь buildreq-src, полученный хлам используешь в hsh-initroot и
> уже там запускаешь buildreq.

Это одно применение, а второе важное применение ---
не потеряли ли мы в процессе сопровождения пакета
какую-то важную опциональную зависимость.

Т.е. по хорошему после каждого обновления надо
перечитывать те же configure.ac/CMakeLists.txt.

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

А утилита дает возможность, так сказать, "машинным зрением"
просмотреть и проверить.
Другое дело, что не идеальна еще утилита.


-- 

I V

Re: [devel] I: Утилита buildreq-src

[Sergey V Turchin]

On Wednesday, 16 March 2016 12:18:10 MSK Igor Vlasenko wrote:
> On Wed, Mar 16, 2016 at 11:21:12AM +0300, Anton Farygin wrote:
> > buildreq-src нужен для того, что бы не устанавливать все devel пакеты себе
> > в хост-систему.
> > 
> > т.е. - выполняешь buildreq-src, полученный хлам используешь в hsh-initroot
> > и уже там запускаешь buildreq.
> 
> Это одно применение, а второе важное применение ---
> не потеряли ли мы в процессе сопровождения пакета
> какую-то важную опциональную зависимость.
> 
> Т.е. по хорошему после каждого обновления надо
> перечитывать те же configure.ac/CMakeLists.txt.
Во время configure/cmake они сами рассказывают, чего не хватает.

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

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

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 01:24:26PM +0300, Sergey V Turchin wrote:
> > Т.е. по хорошему после каждого обновления надо
> > перечитывать те же configure.ac/CMakeLists.txt.
> Во время configure/cmake они сами рассказывают, чего не хватает.

Увы и ах. я сейчас не помню конкретные имена,
но среди того списка 20 c*.src.rpm который к вечеру подготовлю,
есть живые примеры, которые без явного пинка в виде
--enable foo не чесались чего-либо проверять или рассказывать.
 
-- 

I V

Re: [devel] I: Утилита buildreq-src

[Sergey V Turchin]

On Wednesday, 16 March 2016 12:36:19 MSK Igor Vlasenko wrote:
> On Wed, Mar 16, 2016 at 01:24:26PM +0300, Sergey V Turchin wrote:
> > > Т.е. по хорошему после каждого обновления надо
> > > перечитывать те же configure.ac/CMakeLists.txt.
> > 
> > Во время configure/cmake они сами рассказывают, чего не хватает.
> 
> Увы и ах. я сейчас не помню конкретные имена,
> но среди того списка 20 c*.src.rpm который к вечеру подготовлю,
> есть живые примеры, которые без явного пинка в виде
> --enable foo не чесались чего-либо проверять или рассказывать.
Ааа, да. Бывают такие, но зачастую они и не рекомендуют с этим собирать.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 11:10:01AM +0300, Sergey V Turchin wrote:
> Полезность buildreq-src получается сомнительная, т.к. мне, например, обычно 
> хочется, чтобы кто-то умел чистить то, что делает buildreq. 

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


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

С базовым набором зависимостей проблем нет -- программа просто не
соберется без базового набора зависимостей.
А с опциональными зависимостями как раз и проблемы --
программа собирается и работает, но части возможностей
нет. Или звука нет, или сети, или не открывается что-то и т.д.

Я вот сделал эксперимент, прогнал через утилиту пакеты Сизифа 
на с*. на 400 пакетов 20 недособраны (по недосмотру урезана
функциональность).

5% в масштабах Сизифа -- это очень и очень много.

И как такие проблемы выявлять без утилит наподобие
buildreq-src, непонятно.



-- 

I V

Re: [devel] I: Утилита buildreq-src

[Хихин Руслан]

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

Здравствуйте !
On Wednesday 16 March 2016 12:46:58 Igor Vlasenko написал(а):

> Я вот сделал эксперимент, прогнал через утилиту пакеты Сизифа
> на с*. на 400 пакетов 20 недособраны (по недосмотру урезана
> функциональность).

А где-то озвучить список этих пакетов нельзя? Я думаю, это всем интересно.
Кстати, если мне придёт письмо от робота, а такой возможности в каком-то моём 
пакете, я был-бы очень рад :)

ЗЫ Хорошее это дело вы "затеяли".

-- 
C уважением, Хихин Руслан.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 01:12:40PM +0300, Хихин Руслан wrote:
> Здравствуйте !
> On Wednesday 16 March 2016 12:46:58 Igor Vlasenko написал(а):
> 
> > Я вот сделал эксперимент, прогнал через утилиту пакеты Сизифа
> > на с*. на 400 пакетов 20 недособраны (по недосмотру урезана
> > функциональность).
> 
> А где-то озвучить список этих пакетов нельзя? Я думаю, это всем интересно.

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

> Кстати, если мне придёт письмо от робота, а такой возможности в каком-то моём 
> пакете, я был-бы очень рад :)

К сожалению, утилита еще не совершенна,
надо, чтобы человек просматривал ее выхлоп.
Но это уже прогресс -- посмотреть выхлоп утилиты
в 100 раз проще, чем исходники вычитывать.

-- 

I V

Re: [devel] I: Утилита buildreq-src

[Anton Farygin]

On 16.03.2016 13:22, Igor Vlasenko wrote:
> К сожалению, утилита еще не совершенна,
> надо, чтобы человек просматривал ее выхлоп.
> Но это уже прогресс -- посмотреть выхлоп утилиты
> в 100 раз проще, чем исходники вычитывать.

А зачем вычитывать исходники, если можно посмотреть выхлоп configure
???

[devel] ужасные исходники [ I: Утилита buildreq-src]

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 04:40:40PM +0300, Anton Farygin wrote:
> On 16.03.2016 13:22, Igor Vlasenko wrote:
> >К сожалению, утилита еще не совершенна,
> >надо, чтобы человек просматривал ее выхлоп.
> >Но это уже прогресс -- посмотреть выхлоп утилиты
> >в 100 раз проще, чем исходники вычитывать.
> 
> А зачем вычитывать исходники, если можно посмотреть выхлоп configure
> ???

Потому что надеяться на выхлоп configure, это как 
надеяться на вменяемость апстрима.

Хорошо, когда она есть, но никто ее не гарантирует.

Вот пример из жизни: [ cfitsio-3.370/configure.in ]

AC_ARG_WITH(
  bzip2,
  [AS_HELP_STRING([--with-bzip2[[=PATH]]],[Enable bzip2. Optional path to the he
ader file bzlib.h])],
  [ if test "x$withval" != "xno"; then
        if test "x$withval" != "xyes" ; then
            CFLAGS="$CFLAGS -I${withval}"
        fi
        AC_CHECK_HEADERS(bzlib.h)
        HAVE_BZIP2=yes
        AC_DEFINE(HAVE_BZIP2,1,[Define if you want bzip2 read support])
    fi
  ],
  [AC_CHECK_HEADERS(bzlib.h)
   HAVE_BZIP2=yes
   AC_DEFINE(HAVE_BZIP2,1,[Define if you want bzip2 read support])
  ]
)

-- 

I V

Re: [devel] I: Утилита buildreq-src

[Igor Vlasenko]

On Wed, Mar 16, 2016 at 07:23:12AM +0300, Hihin Ruslan wrote:
> Спасибо за ваш инструмент. Попробовал на palemoon:
> 
> BuildRequires: libssl-devel perl(Archive/Zip.pm) perl(CGI.pm) 
> perl(CGI/Carp.pm) perl(Carp.pm) perl(DBI.pm) perl(Errno.pm) 
> ..............
> perl(base.pm) perl(diagnostics.pm) perl(strict.pm) perl(subs.pm) 
> python-devel texinfo

Спасибо!

Упомянутая вами простыня действительно слишком раздута
пакетом perl-base, при чем в виде списка на двадцать позиций.
Однако perl действительно нужен для palemoon. Из лога сборки:
[...]
checking for perl5... /usr/bin/perl5
checking for minimum required perl version >= 5.006... 5.022001
checking for full perl installation... yes
checking for perl5... /usr/bin/perl5
checking for perl5... (cached) /usr/bin/perl5
checking for minimum required perl version >= 5.006... 5.022001
checking for full perl installation... yes

Если просто добавить
BuildRequires: perl, то указанная простыня пропадет.
И это имеет смысл: сейчас perl не прописан в BuildRequires
у palemoon, но вытягивается кем-то по зависимостям
помимо вашей воли и контроля.
Завтра может и перестать вытягиваться.

-- 

I V

Re: [devel] I: Утилита buildreq-src

[Anton V. Boyarshinov]

В Wed, 16 Mar 2016 10:49:32 +0200
Igor Vlasenko <vlasenko@imath.kiev.ua> пишет:

> И это имеет смысл: сейчас perl не прописан в BuildRequires
> у palemoon, но вытягивается кем-то по зависимостям
> помимо вашей воли и контроля.
> Завтра может и перестать вытягиваться.
perl-base вытягивается пакетом rpm-build

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