Как опакечивают Java-программы в Gentoo?

Начало драмы там - Как установить Protege? (комментарий)

Maven - это не просто система сборки, это менеджер пакетов. Можно считать Java виртуальной операционной системой, в которой уже есть свой опакечиватель :)

Я как Java-разработчик всячески за то, чтобы никто не пытался «опакечивать» Maven (и Gradle, что одно и то же)

Никакие зависимости из Maven **не** должны зеркалироваться в пакеты пакетной системы операционной системы. Попытка это сделать приводит к трудноуловимым багам и чудовищным затратам на поддержку.

Всё что может сделать создатель «пакета Java-приложения» - это вызвать `mvn clean install` в корне джавных исходников и ждать, пока на выходе где-то не появится набор JAR-файлов. Обычно это какая-то часть содержимого директории target. Получившееся берется как есть и пихается в совершенно любое место файловой системы.

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

Особо отмечу, что если ты натравил mvn clean install на какой-то произвольный репозиторий на гитхабе, директория target - это не готовая какая-то папка, на которую можно вызвать make install и она сама по себе встанет. Джавовские приложения по умолчанию вообще ничего не знают ни о каком GNU/Linux, и «деплоить» их на целевую машину могут и умеют только непосредственные разработчики этого софта (ну или те, кто прочитал документацию и запускает по инструкции на сайте).

Поэтому «правильная» поддержка Maven/Gradle/Sbt/... в Gentoo кажется действительно большой задачей, и кажется, что смысла в ней никакого нет. Лучше качать бинарники, которые правильным способом приготовили и выложили у себя создатели соответствующего софта, и вот эти бинарники уже можно опакетить

Ты предлагаешь при установке пакета на целевую систему жаба-поделки дергать mvn package?

Смотря кому.

Если ты про ТС... Ну я так понял, ТС именно это и хочет сделать. Это ж Gentoo, там принято всё из исходников.

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

Если же ты про разработчиков дистрибутива, я предлагаю им перестать бредить идеей брать dependencies из pom.xml и пытаться превратить их в отдельные какие-нибудь deb-пакеты, чтобы потом связывать их через CLASSPATH. Эта идея кажется хорошей только до тех пор, пока не поймёшь, что разработчики софта про неё ничего не знают, и например, какой-нибудь log4j-1.2.3.jar в двух разных программах может быть собран категорически несовместимым образом. Или что например, spring-1.2.3.jar зачастую нельзя проапгрейдить на spring-1.2.4.jar без того чтобы приложение перестало запускаться. Это какой-то очень долго доказываемый факт, но по результатам доооолгой практики для меня это вполне себе факт, подтвержденный статистикой: опакечивать Java-зависимости нельзя. Java-приложение - это «всё своё тащу с собой». Если бы я делал какой-то серьёзный продукт, я бы даже собственный билд OpenJDK засунул прямо внутрь дистрибутива программы от греха подальше.

Плюс, скорей всего, после отработки результата mvn package, софтина работать не начнёт :) Нужно будет писать ещё килотонну скриптов вручную, чтобы её правильно запустить. Это некое тайное знание, которое нужно экстрагировать чтением сайта соответствующей софтины и регулярным слежением за изменением руководств по установке. Чего мантейнеры дистрибутива, конечно делать не станут. Там в дистрибутивах всякие олдскульные линуксоеды, которые чисто верят, что после make install всё работает само собой - и нет, не работает. После осознания, что ничего не работает, они начинают метаться и писать чудовищные костыли и патчи, в надежде не разбираясь в вопросе и не читая документацию хоть как-то хоть что-то запинать чтобы заработало. Драматическое зрелище.

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

Как какую-то васянскую проприетарщину, ага

Согласен. Просто не верно тебя понял сначала.

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

Вера java-девелоперов в особую божественность java, ага.

Вообще завязывание всего на свою языковую пакетную систему - это стандартная болезнь узко специализированных разработчиков. Не зависящая от языка. Просто java прошла по этому пути сильно дальше чем go, Python и другие. Прочим приходится сосуществовать в мире различных технологий и учиться зависеть от внешнего мира.

А выколупать джависта из его жабной экосистемы - этого пятью годами модуляризации и непрерывной маркетинговой трепотней про devops так легко не сделать.

unsupported build system such as Gradle or Maven

нет Gradle и Maven - считайте, что нет Java. Опакечивайте что-нибудь другое.

Вера java-девелоперов в особую божественность java, ага.

Бред.

Флатпак (для десктопа) и докер (для сервера) полностью решают проблему распространения JVM-приложений.

https://flatkill.org/

+1, еще snap есть.

опакечивают Java-программы в Gentoo?

https://i0.wp.com/defence-line.org/wp-content/uploads/2018/10/307134.jpg?ssl=1

Джаву нету ни смысла собирать в байткоды на целевой машине, ни делать jar shared. От этого ни ощутимо не экономится место на диске, ни ОЗУ. Также в Java не принято делать USE флаги сборки.

Потому только -bin пакеты с зависимостью на openjdk (или какой-то virtual, я не шарю как правильно)

Зато есть гарантии! Что собрано именно из исходников, с лицензиями и нет ничего лишнего в бинарниках.

Я как Java-разработчик всячески за то, чтобы никто не пытался «опакечивать» Maven

Rust пакеты эти супостаты тоже упорото пакуют. Слава богу хоть не по зависимости отдельно. Но все версии пакетов тупо пакуются в ebuild, вместо того чтобы реюзать Cargo.lock.

https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/ripgrep/ripgrep-11.0.2.ebuild

Я так понял причина в том, что они хотят на зеркалах Gentoo кешировать crates с Cargo.io, чтобы зеркал Gentoo герметично хватало для сборки. Но все равно могли бы хотя бы как-то доверять Cargo.lock, написать свой парсер для него.

cargo ebuild сам генерирует эту лапшу, но локально. В Gentoo реп уже коммитишь этот список убогий

Что собрано именно из исходников

А иначе собрано с чего, из святого духа?

Я за то чтобы известные CI, с хорошей репутацией, делали builds и подписывали их своими ключами. И ты бы видел конфиг сборки там.

Для натива хотя-бы есть смысл делать танцы с Gentoo. Там сборка под целевую платформу и флаги есть смысл включать compile time

Считать набор jar’ов одним бинарём и максимум, что устанавливать в зависимости - это JRE. С модульными приложениями Java 9+ - и этого делать не надо.

Убери в виртуалку/контейнер. Кроме того, Java приложения достаточно легко декомпилировать и осознать (по сравнению с тем же C++).

Странно, что они тупо не подняли локальный Gentoo Alternate Cargo Registry какой-нибудь и выковыривают приложение из его системы сборки.

А иначе собрано с чего, из святого духа?

А иначе непонятно, каких туда троянов засунули по дороге.
То исходники понятно какие - в distfiles, можно посмотреть, хэш проверяется. И для сборки нужен только репозиторий дистрибутива, ведь что там за сервера maven, и будут ли они доступны, когда тебе понадобится что-то собрать - ещё вопрос.

Мы же про дистрибутивные репозитории, а не про уяк-впродакшон

Дистрибутивные репозитории далеко не всегда отличаются качеством.

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

Я ведь уже сказал: достаточно сделать зависимость от конкретной JVM и не мейнтейнить зависимости, один хрен мозгов не хватит для обеспечения корректной работы специального приложения. Тем более, если разработка десктопа ведется на Java - значит тупо бюджета компании-разработчика хватает только на Java приложения при необходимости кроссплатформенной работы. Нормальное приложение не окупится.

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

Т.е. просто брать блоб в виде jar-файла, скачанный откуда-то, неизвестно как собранный, и опакечивать?
Ну ты же понимаешь, что ни один уважающий себя дистрибутив так делать не будет, если это не проприетарщина by design (как какой-нибудь skype, steam или драйвер nvidia), и то тогда этот пакет пойдёт куда-нибудь в non-free, а не в основную ветку репозитория.
Потому что если есть исходники, должна быть гарантия

Что собрано именно из исходников, с лицензиями и нет ничего лишнего в бинарниках.

Да, брать блоб и опакечивать.

И да, в non-free. Много ли ты знаешь Java-приложений не для специального применения?

Кроме того, объём кода в этих приложениях обычно превышает способности одного человека осознать и обеспечить какие-либо гарантии, не надо заниматься самообманом.

Я сейчас работаю над приложением, в котором под 80к строк кода. Одна его основная зависимость - ещё +100к строк кода, остальные - могут быть и того больше. Разбираюсь уже 3-ий месяц, до сих пор не расковырял логику полностью, поскольку логика нетривиальная + кривоватый многопоток, не говоря уже о обеспечении каких-то гарантий безопасности.

Кроме того, иногда встречаю поведение, когда поменяли публичный API у библиотеки - но вместо 2-ой цифры semver подняли третью. Обновляешься - получаешь весёлые развлечения. Я, как разработчик - смогу продиагностировать своё приложение и починить проблему, а не подставить временный костыль. И то, если этот код писал я, либо с этим кодом я уже работал не раз и не два. Мейнтейнер, который не является разработчиком - подавит явный ахтунг, но взамен поломает стабильность приложения в целом, получит утечку памяти, нестабильно повторяющиеся баги с многопотоком и др. Если же он погрузится до уровня разработчика - то это уже и не мейнтейнер. Но это работа на фултайм, и такое никто не оплатит, если только не мейнтейнит на заказ.

Забудьте о том, что мейнтейнер что-то вам обеспечивает. Если приложение стремное, ещё и бинарём - в изолированное окружение его и в non-free.

Много ли ты знаешь Java-приложений не для специального применения?

Это другой вопрос. Тогда собственно зачем вообще это тащить в дистрибутив и пакетировать?

объём кода в этих приложениях обычно превышает способности одного человека осознать и обеспечить какие-либо гарантии, не надо заниматься самообманом

Как объём кода любого крупного проекта, хоть gcc, хоть libreoffice, хоть ядра.
Мейнтейнер не обеспечивает гарантию, что там нет каких-то троянов или что-то типа того, а только то, что бинарный пакет собран конкретно из этого кода.
При этом ничего плохого в принципе «всё своё с собой», можно в пакет исходников положить исходники всех зависимостей нужных версий с нужными патчами. Как вон для руста в генте, и волки целы, и овцы сыты.

ничего плохого в принципе «всё своё с собой», можно в пакет исходников положить исходники всех зависимостей нужных версий с нужными патчами.

И для этого есть механизм слотов. Слот можно и на минорную версию SemVer прицепить.

Это какой-то FUD.

Обновления безопасности - единственный внятный пункт (старый аргумент за динамическую линковку против статической). Есть инструменты, позволяющие разработчику в рамках CI следить за уязвимостями и реагировать на них, выпуская новые релизы.

Про minor security issue - ну это вообще переврали, в оригинале «minor security update». То есть не проблема минорная, а апдейт минорный - не требующий внимания пользователя.

Про песочницу не аргумент, в системных (deb/rpm/ebuild) пакетах ее тоже не наблюдается. Нужна песочница - осиль selinux или apparmor.

Про песочницу не аргумент, в системных (deb/rpm/ebuild) пакетах ее тоже не наблюдается

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

Как опакечивают Java-программы в Gentoo?

https://gitweb.gentoo.org/repo/gentoo.git/tree/net-p2p/bisq/bisq-0.6.3.ebuild
кокая кросота!