Создавать ли багу в багтрекере?

Поскольку как говорят дистрибутив в легком забвении (aka стагнации), то сразу прикладывай исправленный ebuild. Если даже в общую кучу не попадет, кому нужно найдет в багтрекере и скачает.

дистрибутив в легком забвении (aka стагнации)

А что с ним «не так»? Вроде бы декларируют дружелюбность, вроде бы обещают менторов новичкам.

Угадал автора по первому абзацу.

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

вики тоже выглядит не сильно активной

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

Гента просто полумертва.

Ну хорошо. А существуют ли вообще опенсорсные проекты, которые не зомби?

Если из дистрибутивов — Arch например. Если просто из софта — то KDE, Blender, Inkscape и тд.

из дистрибутивов — Arch например

ну нет, не верю. Гента технологически круче.

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

Чем круче?

Чем Арч.

А что с ним «не так»?

Контролирующих пакеты - мало. Новичков - мало. Отдельной корпорации «усиленно» занимающуюся дистрибутивом - нету.
Собственно это все причины «легкого забвения».

Новичков - мало

А что же это мемберы дистрибутива не занимаются рекрутингом и онбордингом?

понятии не имею, я чисто пользователь, максимум создание своих под свою специфику.
И думаю таких абсолютное большинство

А что же это мемберы дистрибутива не занимаются рекрутингом и онбордингом?

Ебилдинг и компилинг всё свободное время занималинг.

Может быть ещё дело в том, что они требуют именно английский языкинг? Может если бы разработка была многоязыковой, то стало бы лучше?

даже в таком малоиспользуемом дистрибутиве как NixOS

Нужен тег nixos, иначе может не сработать.

21 с 9 октября в мастере.

Нужен тег nixos, иначе может не сработать.

Не нужен. Я не использую этот дистрибутив, поэтому мне не важно что там.

Но разжигаете.

Пользователи NixOS не поддерживают мою веру в то, что всё должно собираться из исходников. Устанавливать бинарники допустимо для них.

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

Есть мнение, что ChromeOS внутри собирается посредством Portage. Конечно, на репозиторий это влияет крайне опосредованно.

могут

Но в Gentoo это освящено гайдлайнами, а в NixOS над вами начнут глумиться с особенным цинизмом.

ChromeOS внутри собирается посредством Portage

скорее это действительность. А репа у них - точно своя.

version bump можно сделать и самому.Насколько я помню, Вам уже объясняли, что новые ebuild’ы можно засылать в guru. Даже без дальнейших обязательств по поддержке ebuild’a. Сколько можно создавать подобные темы?

новые ebuild’ы можно засылать в guru

Смысла в этом нет. Билды надо засылать туда, где есть люди с такими же наклонностями. Т.е. джавовые билды в Java-репозиторий, haskell билды в репозиторий ::haskell и так далее.

Сколько можно создавать подобные темы?

А в чём проблема? Жалко электронов на сервере?

Наверняка ебилд уже есть в оверлеях. Или бампни сам версию или притащи оверлей.
(Напоминаю, что с другим дистром ты бы в подобной ситуации остался с бибой т.к дособрать пакет было бы сильно сложнее)

Наверняка ебилд уже есть в оверлеях.

Да откуда, если java-команда в разброде и шатаниях?

или притащи оверлей

Меня смущает наличие «USE=javafx» и то, что он в круглых скобочках (кстати, что это значит?)

Или бампни сам

ой, всё.

openjfx я отдельно ставил. Может поддержка javafx в самом пакете не сильно кому-либо нужна?
Замаскировано оно всё скорее всего потому что на оффициальных сайтах явы полный беспорядок и ничего скачать нельзя

на оффициальных сайтах явы полный беспорядок

У генты есть зеркала. На них-то можно было бы порядок навести? Если нельзя, то кто виноват?

Возможно, лицензия, которая требует принять EULA на сайте чтобы скачать и соответственно запрещает раздавать с зеркал? Всю жизнь помню, когда ставил не openjdk, был fetch restriction

GPL-2.0:
https://github.com/openjdk/jfx/blob/master/LICENSE
тоже:
https://github.com/openjdk/jdk/blob/master/LICENSE

кто виноват?

Ты?

было бы сильно сложне

Почему?

Потому что там запакетировать новую версию самостоятельно сильно сложнее

Где? Во всех дистрибутивах, кроме генты? Шутишь?

В дебианах в целом так. Но вообще от дистрибутива коненчо зависит. В арче так то неплохо с этим pkgbuild/aur справляется

Чем дольше будете сидеть на генте, тем больше будет ваш локальный оверлей.

Таков путь.

«USE=javafx» и то, что он в круглых скобочках (кстати, что это значит?)

Если имя USE-флага заключено в круглые скобки при выводе списка USE-флагов для пакета, это означает, что этот флаг замаскирован. Например, если вы видите флаг (-flag), это означает, что флаг замаскирован и не может быть активирован.

Замаскированные флаги не влияют на процесс сборки пакета и не могут быть активированы или деактивированы пользователем. Это может быть полезно, когда флаг несовместим с текущей системой или когда его активация может привести к нежелательным последствиям.

Размаскировывают USE-флаги в
<репозиторий>/<профиль>/use.mask
или
<репозиторий>/<профиль>/package.use.mask

я, правда, не вижу, где конкретно этот флаг замаскирован:
https://github.com/gentoo/gentoo/blob/master/profiles/arch/amd64/package.use.mask#L275-L278

# Georgy Yakovlev <gyakovlev@gentoo.org> (2019-06-22)
# openjfx is keyworded on amd64
dev-java/openjdk:8 -javafx
dev-java/openjdk:11 -javafx

https://github.com/gentoo/gentoo/blob/master/profiles/arch/amd64/package.use.stable.mask#L80-L84

# Georgy Yakovlev <gyakovlev@gentoo.org> (2021-05-07)
# openjfx:8 will never be stabilized
# openjfx:11 probably will neither
dev-java/openjdk:8 javafx
dev-java/openjdk:11 javafx

я не вижу, потому что тут ничего не написано про openjdk 17 и 21, а замаскирован флаг именно у них.

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

https://github.com/gentoo/gentoo/blob/master/dev-java/openjdk/openjdk-21.0.1_p12.ebuild#L34

# don't change versioning scheme
# to find correct _p number, look at
# https://github.com/openjdk/jdk${SLOT}u/tags
# you will see, for example, jdk-17.0.4.1-ga and jdk-17.0.4.1+1, both point
# to exact same commit sha. we should always use the full version.
# -ga tag is just for humans to easily identify General Availability release tag.
MY_PV="${PV%_p*}-ga"
SLOT="${MY_PV%%[.+]*}"

https://github.com/gentoo/gentoo/blob/master/dev-java/openjdk/openjdk-21.0.1_p12.ebuild#L101

javafx? ( dev-java/openjfx:${SLOT}= )

https://github.com/gentoo/gentoo/tree/master/dev-java/openjfx

openjfx-11.0.11_p1-r1.ebuild
openjfx-11.0.9_p0-r1.ebuild
openjfx-8.1000-r1.ebuild

здесь да, нет .ebuild-файла с таким же слотом

MY_PV="${PV%_p*}-ga"

bash заменит ${PV%_p*} на значение переменной PV, удалив самую длинную подстроку, соответствующую шаблону _p*

MY_PV=«21.0.1-ga»

https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html

SLOT="${MY_PV%%[.+]*}"

В Bash, когда вы используете %% в параметрическом расширении, это означает, что вы хотите удалить самую длинную подстроку, соответствующую шаблону, с конца строки.

bash заменит ${MY_PV%%[.+]*} на значение переменной MY_PV, удалив самую длинную подстроку, соответствующую шаблону [.+]* с конца строки.

openjdk-21.0.1_p12.ebuild

SLOT=«21» или SLOT=«2» ?

PV="21.0.1_p12"
MY_PV="${PV%_p*}-ga"
SLOT="${MY_PV%%[.+]*}"

echo "${SLOT}";

выводит 21, но мне непонятно, почему.
https://www.gnu.org/software/bash/manual/html_node/Pattern-Matching.html

Пробовал убрать «+» (SLOT="${MY_PV%%[.]*}"), ничего не поменялось.
И квадратные скобки пробовал убрать (SLOT="${MY_PV%%.*}"), то же самое…