[devel] О зависимостях R — Re: Бага #32537

[Kirill Maslinsky <kirill@altlinux.org>]

Андрей Черепанов writes:

> 21 марта 2018 г. 20:29:59 Восточноевропейское время, "Илья Захаров" <ivz@basealt.ru> пишет:

>>> Однако хотелось бы, чтобы реально работал механизм исправления багов,
>>ибо по #32537 нет не только исправлений, но даже и значимой реакции (
>>баге больше года).

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

>>>>> В репозитории есть пакет R-base (уже устаревший)

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

>>>>> Результаты своих экспериментов по установке, обновлению и
>>добавлению пакетов описал в списке новых багов:
>>>>> 32537 NEW nor Branch p R-base cas@altlinux.org ikh1@yandex.ru Не
>>устанавливаются пакеты с зеркал CRAN

см. выше

>>>>> 34678 NEW nor Branch p R-base cas@altlinux.org ikh1@yandex.ru
>>Требуется зависимость на R-devel
>>>>> 34679 NEW nor Branch p R-base cas@altlinux.org ikh1@yandex.ru
>>Требуются зависимости на библиотеки Фортрана
>>>>> 34680 NEW nor Branch p R-base cas@altlinux.org ikh1@yandex.ru
>>Требуется зависимость на компилятор Фортран
>>>>> 34682 NEW nor Branch p R-base cas@altlinux.org ikh1@yandex.ru
>>Требуется зависимость на libnlopt

Не считаю это багами: R-devel и прочие перечисленные компиляторы и
библиотеки являются не зависимостями R, а сборочными зависимостями
устанавливаемых пакетов. Что же теперь, в зависимости R-base запихивать
все мыслимые *-devel пакеты которые могут потребоваться хоть кому-то на
CRAN? Не считаю такое решение оправданным.

При этом согласен, что для неподготовленных пользователей установка
сборочных зависимостей для компиляции кода R-пакетов представляет
известные трудности. Чтобы их минимализировать, можно сделать две вещи:

1. На уровне репозитория: сделать какой-нибудь метапакет, который будет
зависеть от R-base, R-devel, R-tcltk.
можно ли назвать пакет просто R ? или как еще — мне все равно, предлагайте.

2. На уровне дистрибутива: если R — это один из рабочих инструментов в
дистрибутиве и есть юзкейс с установкой R-пакетов, осмысленно включить в
дистрибутив стандартную сборочную среду, куда должны входить как минимум
R-devel, R-tlctk, gcc-c++ gcc-fortran liblapack-devel (если gfortran от
него не зависит, не помню), в некоторых случаях libicu-devel, ну дальше
уже варианты, бывают пакеты, которые требуют даже GTK. Такого рода
проблемы решаются уже на уровне документации.

>>>>> Все это разрешимо средствами репозитория, но на одном рабочем месте
>>я потратил на борьбу с багами почти час.
>>>>> А что будет (и какова будет реакция "пользователей"), если это
>>придется делать в 2-3 классах по 15 рабочих мест?

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

--
КМ