Dmenu нет(

apt show dmenu
Package: dmenu
State: not a real package (virtual)
N: Can't select candidate version from package dmenu as it has no candidate
N: Can't select versions from package 'dmenu' as it is purely virtual
N: No packages found

dmenu - это виртуальный пакет. Функционал при его запросе предоставляет другой:

apt-cache showpkg dmenu
Package: dmenu
Versions:

Reverse Depends:
  xmonad,dmenu
  ytfzf,dmenu
Dependencies:
Provides:
Reverse Provides:
suckless-tools 47-1 (= )

Если не знаешь утилит - читай логи apt, там будет ответ что было поставлено при каком запросе.

очень странная фигня в дебиане с dmenu. так-то это совершенно отдельная софтина, с отдельным функционалом, никак не относящаяся к другим утилитам от suckless. они даже и тут из suckless умудрились сделать какой-то невменяемый агломерат.

А это что тогда и почему?

https://tools.suckless.org/dmenu/

https://suckless.org/

Так что все правильно по пакетам.

Логика у дебиановцев интересная, конечно. То разобьют один пакет на 2-3-5-inf, то возьмут очевидно разные программы и зачем-то запихнут их в один пакет.

А это что тогда и почему?

Это ссылка на отдельный dmenu и ссылка на заглавную страничку suckless. Не уверен, какую идею ты хочешь донести.

Ту, что указанный набор утилит, поставляемый в debian в одном пакете относится технически к одному проекту, есть сайт проекта, suckless.org, с описанием, входящих в проект утилит, в том числе и dmenu.

Утилиты вполне логично можно включить а один пакет.

Ту, что указанный набор утилит, поставляемый в debian в одном пакете относится технически к одному проекту, есть сайт проекта, suckless.org, с описанием, входящих в проект утилит, в том числе и dmenu.

Утилиты вполне логично можно включить а один пакет.

Только вот утилиты значительно отличаются по сфере применения. Нормально ли группировать такую гетерогенную группу вместе?

А штуки типа gnome и kde в дебиане по одному пакету занимают? Давно не использовал, но что-то сомневаюсь.

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

xssstate-1.1.tar.gz                                01-Jul-2017 12:58                3725
tabbed-0.9.tar.gz                                  09-Aug-2025 13:03               14484
swarp-0.1.tar.gz                                   01-Jul-2017 12:58                2277
svkbd-0.4.2.tar.gz                                 26-Nov-2024 17:31               24782
ssid-0.1.tar.gz                                    01-Jul-2017 12:58                2072
sselp-0.2.tar.gz                                   01-Jul-2017 12:58                2562
sprop-0.1.tar.gz                                   01-Jul-2017 12:58                2750

Млять, мантейнер принял решение выпускать один пакет, чем городить 10 пакетов из-за утилит, часть исходных кодов которых, пусть и в архиве, но все же весят 2кб, где-то 15кб, это вообще ни о чем.

Выпускает себе общий пакет,

В установленном виде вообще 300кб эти утилиты весят.

Фигли ты ноешь, что вместо 15 отдельных пакетов по несколько килобайт тебе сделали один?

Хочешь - опакеть каждую утилиту в отдельный деб пакет себе и ставь, вместо 300кб будет 2кб или 20кб, только тех, что тебе надо.

Я не понимаю.

Виртуальные пакеты, автор прописал.

Т.е. если ты напишешь apt install dmenu - у тебя составится один пакет с набором утилит и займет на диске 300 КБ.

Вместо того, чтобы поставить один отдельный пакет толькос dmenu, допустим он бы занял у тебя 5 КБ

У тебя комплексы маленького накопителя? Сходи купи побольше, если ты считаешь, что допустим 256 Гб ССД - у тебя маленький.

Меня вполне устраивает ситуация. И мантейнера пакета тоже, что вместо работы с 15 пакетами в баг трекере при подготовке релиза дистрибутива он работает с одним.

Мантейнер принял решение, что вместо 15 пакетов с утилитами размером в несколько КБ он будет сопровождать один пакет, с утилитами с сайта проекта suckless tools общим размером 300 КБ, чем возиться с сопровождением 15 пакетов при подготовке релиза.

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

Лично меня не беспокоит, что при вызове apt install dmenu по виртуальным пакетам в систему вместо 2-5кб ставится один пакет на 300кб.

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

утилиты группируются в пакеты по смыслу, а не по размеру. как-то так.

Он уменьшает организационные накладки. Это его право. Значит никто не захотел более сопровождать этот набор утилит.

Вы смотрите с точки зрения разработчика, что допустим библиотеки для запуска части утилит нужны одни, для другой - другие.

В целом это не совсем хорошо, но ради 300 Кб утилит и допустим ещё 200 Кб лишних библиотек, когда нужна всего одна утилита и она одна вместе с библиотеками занимала бы 50 Кб вместо 500 Кб спорить смысла нет.

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

Организационных накладок будет в тысячи раз меньше, если в системе будет всего 5 пакетов: kernel, os, kde-plasma, kde-utils, browsers

Предлагаю уменьшить количество пакетов в репозитории штук до 100. (пакет для любителей гномощели, пакет для любителей тайловых vm, пакет со всеми не тайловыми vm и не с DE, пакет графических редакторов и т.п.)

А кому не нравится - пусть комплексы свои закрывают покупкой 10Tb nvme, а не сношают мозги мейтенерам.

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

Зачем передёргивать? В данном случае утилиты сгруппированы по проекту, а точнее сообществу.

This directory contains the tools which have been created or maintained by the suckless community.

https://git.suckless.org/

https://tools.suckless.org/

Здесь вполне всё логично.

Если вас что-то не устраивает - берите дело в свои руки.

КДЕ в топку, не нужно,

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

Т.е. ничего не удалить без удаления остального? Захочешь rofi вместо dmenu, пусть лежит или удаляй всё.

Тебя таки волнуют 300 Кб? Если волнуют - вперёд, берёшь DSC пакета, на его основе пишешь 15 отдельных DSC, собираешь 15 отдельных пакетов, профит.

Ну либо можешь с нуля пройти весь этап подготовки и создания DEB пакета для всех утилит, что тебе нужны из suckless-tools, ну либо только для той, что нужно. Соберёшь deb пакет и будет тебе счастье.

Если тебя что-то не устраивает - бери дело в свои руки, сам собирай, а лучше - бери сопровождение в свои руки. Стань мантейнером и скажи, что конкретно пакет для dmenu из общего набора утилит будешь собирать и поддерживать ты.

Это чисто дебиановский подход. В арче идет самостоятельным пакетом, это гибче на мой взгляд:

$  pacman -Si dmenu | grep -E 'Name|Version|URL|Build\sDate'
Name            : dmenu
Version         : 5.4-1
URL             : https://tools.suckless.org/dmenu/
Build Date      : Sun 10 Aug 2025 03:57:33 PM MSK

Ну так бери дело в свои руки, в чём проблема? )))

Я не понимаю, ну дебиановский подход. Все это понимают. Или ты думаешь, что я этого не понимаю? Что ты мне доказываешь? Что должно быть по другому? Возможно. Что дальше? Если тебя не устраивает - сделай отдельные пакеты, стань мантейнером, в чём проблема? Если так тебя это волнует, зачем писать здесь мне, напиши в Debian.

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

Я лишь показал, что в Debian dmenu - виртуальный пакет и при его установке ставится другой. И как это увидеть.

Мантейнером является

Maintainers for suckless-tools are Aymeric Agon-Rambosson <aymeric.agon@yandex.com>.

Можешь написать прямо ему. Сказать, что ты готов ему помочь собирать отдельные пакеты, тестировать и решать вопросы при подготовке релизов.

Ну вот вы все понимаете, но защищаете ментейнера, который все засунул в один пакет. Так же удобно, подумаешь 300K, а обновлять буду когда все утилиты обновятся, раз в релиз дебиана.

Там утилиты не все обновляются ) Посмотри мои сообщения здесь или сам зайди на сайт suckless.org и посмотри дату релизов утилит, можешь в git.

Версии утилит в Debian вообще не изменятся до выхода следующего стабильного релиза дистрибутива Debian, только баги безопасности будут исправлять.

Если хочется rolling-release, как в Arch - ставь Debian Sid, это unstable ветка, в него постоянно переносятся новые пакеты из ветки experimental, когда там пройдёт минимальная стабилизация.

Или можешь вообще на experimental переключиться.

Тогда будет как в Arch.

Ну так бери дело в свои руки, в чём проблема?

Да сколько можно одно и то же повторять в треде.

Не каждую проблему нужно решать нам - меня дебиан не касается, мне нормально просто пальцем показать и сказать: «посмотрите на этих юродивых».

В генте проекты suckless раскиданы по отдельным ебилдам, мне нормально.

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

А эти «виртуальные» пакеты всё равно кому-то нужно было организовывать, нормально так.

В генте проекты suckless раскиданы по отдельным ебилдам, мне нормально.

Потому, что это rolling-release дистрибутив, так же как Arch Linux.

Debian - релизный дистрибутив. После выхода релиза дистрибутива версии утилит в релизе не меняются, только исправляются баги по безопасности. Т.е. если релиз вышел с утилитой «A» версии 1.0.1 и определённым функционалом, то весь срок поддержки релиза дистрибутива в ней будет версия утилиты «A» - 1.0.1. Если в ней нашли баг безопасности - его исправляют, возможно переносом исправлений из версии утилиты 1.0.2, но только исправление безопасности. Даже если в версии утилиты 1.0.2 был добавлен и новый функционал и допустим новое API, которого нет в 1.0.1 - перенесут только фикс безопасности.

Поэтому поставка набора утилит в одном пакете не влияет на обновление версий.

Версии меняются только при выходе нового релиза дистрибутива Debian.

А вот как обновление этого пакета происходит?

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

Прогу ознакомиться с механизмом выпуска релизных дистрибутивов и Debian в частности.

C Gentoo у меня тоже опыт был, с 2006 по 2018 год, ничего против не имею. Но это rolling-release и там другой подход.

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

Браузеры и прочие пакеты - это не утилиты?

Тут ты прав, с браузерами и ядром - вопрос другой.

Но по сути, как было ядро 6.1, допустим в bookworm, а потом на него были выпущены исправления, до 6.1.157.

Вот что в git по сопровождению пакета с ядром для бранча релиза Bookworm https://salsa.debian.org/kernel-team/linux/-/commits/debian/6.1/bookworm?ref_type=heads

Аналогичная ситуация с chromium: https://salsa.debian.org/chromium-team/chromium/-/commits/bookworm?ref_type=heads

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

В браузерах ситуация немного другая.

Ничосе, опять какого дебианутого порвало в комментах.

Конечно, прямо вообще, жить теперь не могу, даже курил уже 5 раз.

А порвало как раз-таки всех остальных. Если кого-то что-то не устраивает - вперёд исправляйте, меня текущая ситуация устраивает.

А если нет - я сам соберу себе deb пакет отдельно.

Чего и всем желаю смочь.

Тут ты прав, с браузерами и ядром - вопрос другой.

Какой другой? Ну ок. В браузерах маркетологи победили, по их версии вообще ничего не понятно. А с ведром что «другое»?

Ты же сам привёл в пример семантическое версионирование утилиты «А» - X.Y.Z. Что там по правилам? Z - исправления, Y - только добавление нового с обратной совместимостью со старым. X - обратная совместимость не гарантиуется.

В рамках одного релиза дистрибутива вполне могут быть и 1.0.1, и 1.2.75, и 1.6.99, если мейтейнер озаботится проверкой того, что старая функциональность не сломается. А вот любой 1.0.Z быть должен.

Это заскоки исключительно демьяна, что в рамках релиза не должно быть новых Y, и желательно чтобы не было и Z. А не правила для любого «не rr дистрибутива».

Мусьё дэ Артаньян, экскузе муа. Кеви ву облие пар ми ну, ле плебея?

Посмотри, пожалуйста ссылки на git репозиторий выпуска пакетов с ядром.

Для bookworm выпускались обновления Longterm ветки ядра. При выходе релиза Debian Bookworm longterm версия была 6.1.*.

https://salsa.debian.org/kernel-team/linux/-/commits/debian%2F6.1%2Fbookworm?ref_type=heads

Последнее обновление ядра в этой ветке в релизе bookworm было до минорного релиза 6.1.153.

На Kernel.org последнее обновление данной ветки - 6.1.157.

https://kernel.org/

Релиз Debian Trixie вышел с Longterm ядром 6.12: https://salsa.debian.org/kernel-team/linux/-/commits/debian%2F6.12%2Ftrixie?ref_type=heads

А до того как 6.12 стало Longterm и когда Trixie ещё был тестом там были ядра и 6.10.*.

На текущий момент в Debian Trixie ядро версии 6.12.48. А на kernel.org последнее обновление - 6.12.54.

Вот так и будет пока поддерживается релиз Debian Trixie версия ядра 6.12.* и постепенно переноситься патчи из ветки 6.12 с kernel.org.

Ну хоть не «же не манж па сис жюр».

Это заскоки исключительно демьяна, что в рамках релиза не должно быть новых Y, и желательно чтобы не было и Z. А не правила для любого «не rr дистрибутива».

Я что-то говорил другое. Я лишь изложил общую концепцию обновления версий программ (пакетов) в релизе Debian, которая применяется не ко всем пакетам, но к большей части.

Например, исключение - ядро и браузеры.

На вопрос:

чем ведро отличается от другого ПО, что его можно апать по Z, а приведённую тобой «утилиту А» с 1.0.1 до 1.0.2 обновить нельзя

Ты рассказываешь, что мейтейнеры не успевают за апстримом все патчи переносить. Ты адекватный?

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

Вот и начался срач из-за какой-то фигни.

А я чо, я ничего. Это ему не слышно -.-

А тебя кто-то просил вообще что-то писать в эту тему? И всех остальных?

На минуточку.

Вопрос от автора темы был: «Почему я не могу найти dmenu».

Ответ дан в первом сообщении: Dmenu нет( (комментарий)

Понабежали, ноют, что как же так, в Debian, ай-яй-яй. Да пофиг как в Debian и мне пофиг, что остальные думают остальные по этому вопросу.

Если их не устраивает - пускай делают как им нужно.

Писец.

Да-да-да. Всегда так.

Люди вполне корректно обратили внимание на нелогичность в пакетах, а ты кидаться начал, причём матом. Фу таким быть.

PS и сюда клоуна поставь, мне не жалко. Логики твоим сообщениям оно не добавит.

Именно матерного слова от меня здесь нет ни одного.

А по поводу кидаться начал - зачем вы мне всё это пишете. Повторяю ещё раз посыл, в дистрибутиве сделано так, это инструмент.

Если вас всех что-то не устраивает - переделывайте.

Именно матерного слова от меня здесь нет ни одного.

4.2 Первое же слово под списком архивов: Dmenu нет( (комментарий)

Даже если бы тебя peace-door-ball’ом назвал - это был бы мат, поэтому ограничился пунктом правил. А замена одной буквы - уровень совсем детсадовских отмазок «ну мааамаааа, это же другооое слооовооо!!».

Ты русский язык не знаешь? Слово «млять» не является матом. Есть слово на букву «Б», так же есть слово «блин», которое не является матом, так же есть слово «пофиг» и есть слово с буквой X.

Помнится, на БОР, ещё bash.org.ru было что-то вроде:

Участник форума: Модератор, а иностранный мат не запрещён правилами форума?
Модератор: нет.
Участник: Toдi пiшов ...

В общем, считай как хочешь, именно мата здесь не было.