* [devel] О зависимостях R — Re: Бага #32537
@ 2018-03-21 21:21 ` Kirill Maslinsky
0 siblings, 0 replies; only message in thread
From: Kirill Maslinsky @ 2018-03-21 21:21 UTC (permalink / raw)
To: Андрей
Черепанов
Cc: ALT Linux Team development discussions,
Илья
Захаров,
partners, Ivan Khakhaev
Андрей Черепанов 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-пакетами.
--
КМ
^ permalink raw reply [flat|nested] only message in thread