LINUX.ORG.RU
ФорумTalks

вопросы по пакетнику

 , ,


0

1

Откуда такая страсть упаковывать Жаву в пакеты? Стандартные пакетники делались для нативных сишных прог, но у жавы абсолютно другой подход к дистрибуции модулей.

Если уж так сильно хочется ставить пакетником, наверное, для жавных прог нужно иметь какой-то кусок файловой системы со своей нескучной структурой, и какое-то расширение к пакетнику, которое умеет с этой структурой работать? Например, если мы устанавливаем из source-пакета прогу, собираемую Maven, нам нужно уважать скорее правила Мавена, чем что-либо другое. Остальной мэйнстрим (gradle, ivy, ant), тоже весь известен.

То же самое про моно и дотнетные сборки. То же про питон, перл, пхп, руби, и всё остальное, что не написано на Православном и Крестах.

Связанный с этим вопрос. Почему нигде нормально не реализована установка софта на уровне юзера? Т.е. чтобы юзер мог дернуть пакетный менеджер и попросить установить всё в собственный хомячок. В той же винде в инсталляторах есть галка «установить для всех»/«установить только для меня». Например, хочу я поставить Эклипсу, говорю pacman -S --onlyforme eclipse, и он ставит ее в ~/opt/eclipse, линкает экзешник в ~/bin, проверяет что в /etc/profile есть PATH=$HOME/bin, это же так очевидно. И не надо тут про relocate, автоматом это не заработает.



Последнее исправление: CYB3R (всего исправлений: 1)

В той же винде в инсталляторах есть галка «установить для всех»/«установить только для меня».

Не во всех. И вопрос это создания ярлыков/хранения пользовательских файлов, а не размещения самой программы.

AITap
()
Ответ на: комментарий от AITap

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

stevejobs
() автор топика

Ну по идее да, ты прав. А можно права на исполнение просто урезать у всех юзеров и оставить только себе и «релокатить» не надо.

Dron
()
Ответ на: комментарий от stevejobs

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

Это не работает в 99% случаев 8).

Deleted
()
Ответ на: комментарий от stevejobs

Я боюсь попасть впросак, ляпнув глупость, но вроде как никто принципиально не запрещает иметь собственную базу пакетов и вызывать dpkg с соответствующими опциями. Потребуется так же правка $PATH, но за исключением этого, не вижу никаких препятствий.

P.S. С точкой зрения не согласен.

aidaho
()
Последнее исправление: aidaho (всего исправлений: 1)

Почему нигде нормально не реализована установка софта на уровне юзера?

Почти нахрен не нужная опция?

r
()
Ответ на: комментарий от aidaho

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

stevejobs
() автор топика
Ответ на: комментарий от stevejobs

эта опция позволяет почти полностью забить на админа системы

Щаз. В венде ты получаешь диск со всеми зависимостями - можешь ставить «виртуалку» для программы, кторой в лучшем случае нужна венда в худшем еще и .NET. Тут ты получаешь пакеты. Пока ты ставишь «eclipse» все нормально. Что делать c libjpeg?

r
()
Ответ на: комментарий от r

Что делать c libjpeg?

хотите толерастии, равноправия? Пусть будет толерастия! Давайте сделаем опции, которые будут настолько же неудобны для нативных приложений, как для виртуалок неудобно раздирание по пакетам. В частности, libjpeg пусть компиляется из сорцов с префиксом в хомячке пользователя - операция абсолютно идентичная раздиранию жавовских зависимостей по пакетам в дебиане, федоре и всех производных.

stevejobs
() автор топика

Почему нигде нормально не реализована установка софта на уровне юзера?

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

А вообще, я за noexec на хомяке, ибо нефиг.

beka
()
Ответ на: комментарий от stevejobs

rpm поддеживает relocation. Причина почему так не собирают пакеты - многие не relocable в принципе - а те что relocable - такая мелочь что нафиг никто не парится.

r
()
Ответ на: комментарий от stevejobs

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

r
()
Ответ на: комментарий от stevejobs

dpkg на них клал с прибором. Можно просто поставить весь вывод apt-offline и всё.

aidaho
()
Ответ на: комментарий от r

Для виртуалок и интерпретоторов - это принципиально важная фича. Например, чтобы пользователь мог свободно переключаться между реализацией виртуалки (Oracle / OpenJDK) или версией (вспоминаем rvm - ruby version manager, который сам по себе сильно рекомендуется устанавливать в хомячок).

И чтобы не появлялось на лоре тем типа «ставлю эклипсу, как мне сделать, чтобы оно не тянуло openjdk, я пользуюсь оракловским!»

stevejobs
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от r

Разница в том, что между модулями жавы - свои собственные зависимости, которая она отслеживает своими собственными методами. Например, в жаве есть собственный пакетный менеджер, называется Maven. Есть собственные репозитории. По сути, maven-ориентированная коллекция софта - это дистрибутив внутри дистрибутива. Модель пакетов Maven не ложится на модель пакетов dpkg/rpm/pacman. Попытка выдрать модуль maven в отдельный, например, rpm - это какой-то галлюциногенный бред.

stevejobs
() автор топика
Ответ на: комментарий от stevejobs

Ну просто в java чисто случайно уникальный подход с файловой системой в библиотеках. По идее весь eclipse можно запихнуть в один jar. Но это нетипично для других ЯП

vertexua
()
Ответ на: комментарий от vertexua

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

stevejobs
() автор топика
Ответ на: комментарий от stevejobs

Они точно совершенно игнорируют понятие нативной файловой системы, предоставляя универсальную абстрктную?

vertexua
()
Ответ на: комментарий от stevejobs

И чтобы не появлялось на лоре тем типа «ставлю эклипсу, как мне сделать, чтобы оно не тянуло openjdk, я пользуюсь оракловским!» Например, чтобы пользователь мог свободно переключаться между реализацией виртуалки

А как по твоему оно работает сейчас?

r
()
Ответ на: комментарий от stevejobs

Разница в том, что между модулями жавы - свои собственные зависимости, которая она отслеживает своими собственными методами.

Как и между обычными SOшками. Или по твоему ld консультируется с базами пакетника когда либу загружает?

Модель пакетов Maven не ложится на модель пакетов dpkg/rpm/pacman

Да легко. Осталось только мавену собирать соотвествующие пакеты.

Попытка выдрать модуль maven в отдельный, например, rpm - это какой-то галлюциногенный бред.

И в чем же галюцениногенность бреда?

r
()
Ответ на: комментарий от r

Да легко. Осталось только мавену собирать соотвествующие пакеты.

создателям Мавена глубоко срать на Дебиан и Федору, и на десктопный рынок вообще. Мну пользуется Арчей, у нас вся жава монолитно собирается в /opt/$appname - самое лучшее решение в сложившейся ситуации, имхо.

И в чем же галюцениногенность бреда?

во многом! 1) в мавене возможно внутри одного проекта использовать несколько версий одной и той же либы одновременно. Если начать использовать везде одну и ту же версию - всё сломается. Линуксовые пакетные менеджеры для нативных программ (и твоя любимая ld) умеют иметь в системе только одну версию либы. Мну много раз поднимал этот срач в General и Development, с целю установить - как научить ld делать древовидную иерархию зависимостей от либ (чтобы сделать для линукса пакетный менеджер, аналогичный Мавену), но чото никто не смог дать внятного ответа.

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

3) более глобально, весь процесс сборки/установки - динамический, управляющийся наследующимися друг от друга профилями. Что-то подобное может взлететь только на генту, с помощью особой уличной магии. Можно жонглировать репозиториями, кэшами пакетов, набором видимых системных ресурсов, запускать скрипты на jvm-based языках, и многое другое. Можно даже запустить автоматические тесты производительности, и пересобрать программу с другими флагами или библиотеками чтобы работала побыстрее. Половина таких манипуляций приводит к пересборке зависимостей с другими параметрами, что вынуждает иметь несколько вариантов одной и той же зависимости одной и той же версии, что уж совсем плохо ложится на dpkg/rpm

stevejobs
() автор топика
Ответ на: комментарий от stevejobs

Мну пользуется Арчей, у нас вся жава монолитно собирается в /opt/$appname - самое лучшее решение в сложившейся ситуации, имхо

Арчепроблемы. В сусе собираются нормальные рпмки которые работают с той жабой что есть, нормальное переключение альтернатив.

во многом! 1) в мавене возможно внутри одного проекта использовать несколько версий одной и той же либы одновременно

И что по твоему мешает устанавливать несколько версий одной либы одновременно - потусторонние силы?

Если начать использовать везде одну и ту же версию - всё сломается.

Не используй - в чем проблема?

Линуксовые пакетные менеджеры для нативных программ (и твоя любимая ld) умеют иметь в системе только одну версию либы.

rpm -qa | grep x264

libx264-112-0.112svn20110115-1.pm.1.2.x86_64
libx264-120-0.120svn20120126-2.1.x86_64
libx264-106-0.106svn20101002-1.pm.1.1.x86_64
libx264-119-0.119svn20111122-1.1.x86_64
libx264-115-0.115svn20110622-1.pm.1.1.x86_64
libx264-125-0.125svn20120525-1.1.x86_64
libx264-116-0.116svn20110907-1.pm.1.1.x86_64
libx264-107-0.107svn20101016-1.pm.1.5.x86_64
libx264-122-0.122svn20120414-3.1.x86_64
libx264-114-0.114svn20110225-1.pm.2.1.x86_64
libx264-98-0.98svn20100624-0.pm.2.1.x86_64

rpm -qa | grep java-1_6

java-1_6_0-sun-1.6.0.u29-0.2.1.x86_64
java-1_6_0-openjdk-1.6.0.0_b24.1.11.3-0.14.1.x86_64


Пеши есче.

Мну много раз поднимал этот срач в General и Development, с целю установить - как научить ld делать древовидную иерархию зависимостей от либ (чтобы сделать для линукса пакетный менеджер, аналогичный Мавену), но чото никто не смог дать внятного ответа.

Ты предъявляешь претензии не к ld а к жабе - она уметь, она еще более приспособлена для пакетника чем нативные so.

Если всегда говорить, что либа такая-то есть в системе - всё сломается.

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

несколько вариантов одной и той же зависимости одной и той же версии

Ты хоть понимаешь что это феерический бред? Разный код одной версии. Если версия одна - код должен быть бинарно совместим.

r
()
Ответ на: комментарий от Homura_Akemi

И есть способы обойти эти ограничения. Я не утверждаю, что есть готовое решение, скорее наоборот, но принципиальных преград нет. В конце-концов chroot-системы — это подмножество решений, пригодных для той же задачи. Более толсто, но идеологически даже более верно, чем дать пользователю ставить пакеты по отдельности.

aidaho
()

Nix?

Почему нигде нормально не реализована установка софта на уровне юзера? Т.е. чтобы юзер мог дернуть пакетный менеджер и попросить установить всё в собственный хомячок.

Nix умеет.

http://nixos.org/nixos/

http://nixos.org/nix/

Camel ☕☕☕
()
Последнее исправление: Camel (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.