Дистрибутив для розробника?

[BeSiDa]

p.s. забув ще один фактор який враховують для себе - можливість автоматом білдити пакадж зі своїх маніфестів і додавання того репо собі в систему (в багатьох випадках, напевно в більшості, така можливість існує).

А можете деталі розказати? Про який саме "маніфест" мова? Що в ньому?
2
Є випадки, коли користувач навіть думки не має що за нього щось там створюють "з сорців". До прикладу "шейдери" то є "сорци" і вони чи то не при кожному запуску програми та завантаженні кожної вебгл сторінки "компілюються з сорців".
Чи то в лінукс драйвери дкмс. Автоматом. Під ті кернели, що встановлені. Частина з пост-інсталу апт (інтерфейс користувача той самий як бінарник ставити з пакету). От тільки нові віяння з "підписуванням кернела як умова завантаження ос з ефі" трохи то вбивають
Ще всілякі Джіт компіляціі мов програмування.
А сила компілювання в бсд в конфігуре, де можна вибрати що сама з депенденсі хочеш. Ще не весь софт (мабуть)  порозбивали на модулі, що можуть окремо бінарно встановлюватися з конфігами в "інклуде/дір.д/*". Та рідко де в бінарниках є 10 видів того ж самого софта в різних конфігурах часу компіляції (ну ще може буде дві тільки... з Х-ами та клі версії).
А бінарники є для всіх 33.000+ пакетів з портів? На двд лише мала частина.

А от ще, може знаєте... Чи є хоч один пакадж менеджер з 3D чи хоч 2D депенденсі? А то всі (мабуть) 1D (пакет - від - пакетів).
Коли хочеш (у разі користувача) зробити постійним фільтр (для кожної команди пакетного менеджеру щоб не думати потім за це) по типу:
- не хочу QT тому не показуй мені ніколи жоден варіант з пошуку що (хоч в 10-тому рівні депенденсі) має хоч щось що витягне в систему QT,
- не хочу таку-то мову програмування, не показуй нічого, що хоч якось на неї прив'язане,
- в системі тільки такі-то мови спілкування і всі інші пакети з різними мовами жодним чином не показувати,
- в компі така от графічна карта (модель, версія) і всі пакети з драйверами для інших виробників та моделей не показувати (навіть коли драйвер новіше, але вже не має підтримки тої версії обладнання) і так само для іншого обладнання (і команд проца типу ссе),
- не хочу таку-то бібліотеку та технологію (чи то хмл, чи то гіф, чи то формат документу (хтмл замість мєн, щось-там-док і всього стеку тулзів), чи то прив'язки до мережі, чи то до протоколу (не іп-в6)...),
- хотів би отримати з пакетів тільки те, що можна використати без "екрану" (тільки в звуковому використанні і то не тільки "для сліпих", то може бути "в машині за кермом" чи "дейвайс для спорту" та ін),
- і всі такі інші запити "в розріз пакетної структури".

Чи то поки все ще "далеке майбутнє" для мрійників?

так, але... поза netbsd не дуже часто використовується

Аргументація через "розмір натовпу" (або інакше "наскільки то ... попса") вбиває технічний рівень обговорення (приватна думка).
Не забуваймо що в світі мільярди людей і за тим самим аргументом кожен з розробників "маргінал" ))

[yvs115]

А можете деталі розказати? Про який саме "маніфест" мова? Що в ньому?

Все що необхідно для того щоб зібрати пакадж, маніфестом (в аспекті декларативності) їх не завжди повністю можна називати - але зручно щоб не вдаватися в деталі.
Нп все що в debian/ директорії разом, все що в snapcraft.yaml (чи в snap/), абож PKGBUILD чи APKBUILD, абож все що в ports/package чи pkgsrc/package включно з bsd Makefile etc.
Під "автоматом білдити пакадж" дві опції зазвичай - нп такий як aur в arch де знаходиться PKGBUILD і за допомогою yay/paru збирається/ставиться відповідний пакет,
чи нп obs - де не тільки умовно маніфест, а також збирається зразу пакет під відповідні OS (opensuse, fedora, debian, etc.) і який можна прописати-додати як репо і ставити собі зразу бінарний пакадж, і т.д. з launchpad (ubuntu) з snapcraft (snap), etc.

А сила компілювання в бсд в конфігуре

autoconf частина потрохи все менш і менш зустрічається (бо збирають і з cmake і з meson і т.п. сучасні системи конфігурування і білда) - тому опції декларуються через Makefile (або його включення) у відповідних системах, - а далі - у випадку використання autoconf/automake/configure.ac/Makefile.am/configure проходить через configure, а в інших варіантах через їх засоби.

Чи є хоч один пакадж менеджер з 3D чи хоч 2D депенденсі?

- якщо це відносно зовнішнього прописування - так як зазвичай нп cairo(+pango) для 2D, epoxy wrapper для GL, чи cglm для відповідної math, etc.
- якщо це відносно самої GL версіоності - зазвичай в коді (який динамічно компілюється під час runtime) прописується щось з "#version 300 es" чи "#version 400 core", і відповідно отримують мессаджі під час рантайм якщо чогось недостатньо чи по версії чи по наявності extensions.

не хочу таку-то мову програмування, не показуй нічого, що хоч якось на неї прив'язане
Чи то поки все ще "далеке майбутнє" для мрійників?

реалізують той функціонал в якому є актуальна потреба, а фільтрувати бінарні пакаджі по мові сирців - ще не зустрічав такого (хоча напевно можливо в якихось випадках)

Аргументація через "розмір натовпу"

якщо це вразити аспектом унікальності чи екслюзивності якоїсь з опцій - то це не до мене - бо доcтатньо (скажімо так) знайомий з netbsd і з софтом з pkgsrc щоб порівнювати де і як то зручно Ж)

[res2500]

Взагалі, якщо почитати документацію до менеджер який збирає з коду програму він може використати і make, gmake, cmake, bmake ...., головне це вказати в Makefile

[yvs115]

може використати і make, gmake, cmake, bmake ...

серед make які зустрічалися і досі трохи пам'ятаю - gnu make, bsd make, та solaris make (певно xpg4), решту не пам'ятаю,
також в принципі ninja та just також "make" зі своїм використанням,
а от cmake і meson це більш товсті бестії яка заміняють собою configure(+частково make) з autotools.

головне це вказати в Makefile

так, з урахуванням особливостей netbsd make і pkgsrc/mk/

[BeSiDa]

Все що необхідно для того щоб зібрати пакадж, маніфестом (в аспекті декларативності) їх не завжди повністю можна називати - але зручно щоб не вдаватися в деталі.

Дякую, зрозуміло. Тому для бсд з конфігуре "маніфестом" є вся операційна система (у тому її вигляді, яка є на комп'ютері користувача на момент компіляції). Бо якщо користувач не поставив бібліотеку jpeg, то конфігуре змінить налаштування сорців і вони зберуться без підтримки формату зображення jpeg. Або яка з альтернативних бібліотек того ж самого буде обрана, або яка з версій бібліотек та ін. Тобто те що є в системі, а також те чого немає і є "маніфест" (тобто вибір користувача). Але також є меню чи командні параметри додатково, де можна вибрати що вмикати чи вимикати для вибору які частини сорців увійдуть в бінарник (наприклад, що з протоколів вмикати, а що ні).
А яка там з систем збирання, то вже таке. Головне вибір.

реалізують той функціонал в якому є актуальна потреба, а фільтрувати бінарні пакаджі по мові сирців - ще не зустрічав такого (хоча напевно можливо в якихось випадках)

Дійсно не чули такого що хтось не хоче щоб вся інфраструктура Джава, ЦРІ-моно, ТСЛ чи іншого приповзла на комп (навіть коли то тільки рантайм її частина)? Дивина ))
А функціонал "текстового тедактора" чи "перегляд зображень" та ін може бути в десятках різних програм. От з тих десятків і не хочу бачити тих, що побудовані з ...
Та навіть може таке бути що воно іншою мовою програмування створене, а от "плагіни" воно може різними і ... бінарні пакаджі тягнуть всі ті мови... воно то може й не треба йому.

Аргументація через "розмір натовпу"

якщо це вразити аспектом унікальності чи екслюзивності якоїсь з опцій - то це не до мене - бо доcтатньо (скажімо так) знайомий з netbsd і з софтом з pkgsrc щоб порівнювати де і як то зручно Ж)

Слово "вразити" це також інструмент срачу.
Коли є вирішення визначеної людиною задачі, то не важливо ні "вразити", ні "натовп". Досить рівно однієї людини. (замість "знищення всіх хто не в натовпі", хоча дехто від того кайфує... "занурити у багнюку когось, бо ті не масовка").

От Дебіан новий вийшов і там людською мовою пишуть "якщо вам все ще потрібна ця стара архітектура, то зверніть увагу! не оновлюйте систему! бо вже немає її в новій" (замість ставлення "та ви маргінали та винищити вас! бо наші задачі важливіші за ваші! а ви порожнє місце!").

[yvs115]

Тому для бсд з конфігуре "маніфестом" є вся операційна система

Гадки не маю про який configure йде мова, якщо це configure з autoconf то це залежить і що там прописано, і також як все це далі використовується включно з можливою декларацією через Makefile. Сам autoconf/configure.ac/configure (чи нп cmake, чи нп meson) так само відпрацьовує в лінукс. Передача опцій в freebsd/netbsd організована по іншому ніж в linux дистро.

Дійсно не чули такого що хтось не хоче щоб вся інфраструктура Джава,

Популярність java infrastructure в bsd? навіть не цікавився там де є декілька bsd машин.

ЦРІ-моно

навіть не здогадуюсь що то за хрінь)

ТСЛ

tcl(+expect) колись використовував для скриптовки, тікл доволі незначний по розміру, і якщо мантейнер прописав в dependency пакаджу - то мав на то відповідний різон.

Код: [Вибрати]

% pkg_info -R tcl
Information for tcl-8.6.9:
Required by:
tcl-expect-5.45.0nb4
rrdtool-1.7.2nb1

% pkg_info -S 'tcl*' 'rrd*'
Information for tcl-8.6.9:
Size in bytes including required pkgs: 29621534
Information for tcl-expect-5.45.0nb4:
Size in bytes including required pkgs: 27272222
Information for rrdtool-1.7.2nb1:
Size in bytes including required pkgs: 80652863


"текстового тедактора" ... Та навіть може таке бути що воно іншою мовою програмування створене, а от "плагіни" воно може різними і ... бінарні пакаджі тягнуть всі ті мови... воно то може й не треба йому.

neovim? так він своє якщо чогось недостатньо ставить в $HOME і конфігуриться його власними засобами (не системними)

Код: [Вибрати]

% apt-cache depends neovim
neovim
  Залежності (Depends): neovim-runtime
  Залежності (Depends): libc6
 |Залежності (Depends): libluajit-5.1-2
  Залежності (Depends): libluajit-5.1-2
  Ламає (Breaks): neovim-runtime
  Заміняє (Replaces): neovim-runtime
(незважаючи що з ним зараз з десяток плагінів і декілька десятків різноманітних lsp servers)

Слово "вразити" це також інструмент срачу.
Коли є вирішення визначеної людиною задачі, то не важливо ні "вразити", ні "натовп". Досить рівно однієї людини. (замість "знищення всіх хто не в натовпі", хоча дехто від того кайфує... "занурити у багнюку когось, бо ті не масовка").

працюючи ще досі періодично в netbsd і freebsd (хоча і не так багато як колись) - сприймаю філософію зі сторони як там - аби поговорити

От Дебіан новий вийшов і там людською мовою пишуть "якщо вам все ще потрібна ця стара архітектура, то зверніть увагу! не оновлюйте систему! бо вже немає її в новій" (замість ставлення "та ви маргінали та винищити вас! бо наші задачі важливіші за ваші! а ви порожнє місце!").

debian13 доволі зручний, якщо відносно підтримки x86 32bit ядер - то порівнюючи з переходом вже на baselevel x86_64-v2 в багатьох дистро - дебіан виглядає дійсно дуже консервативним якщо тільки розпочав i386 дропити

[BeSiDa]

Гадки не маю про який configure йде мова, якщо це configure з autoconf то це залежить і що там прописано, і також як все це далі використовується включно з можливою декларацією через Makefile.

Чому вас здивувало що в сорцах програми можуть бути #ifdef що вимикають частки коду відповідно до змінних з конфігуре (тестів системи та вибору користувача до початку компіляції)?

Але я запитував про пакетні менеджери та системи керування софтом загалом і здається ви про такі що реалізують ті функції не знаєте. Може й немає таких.
А інше то деталі та приклади.

аби поговорити

Так це ж добре ))

debian13 доволі зручний, якщо відносно підтримки x86 32bit ядер - то порівнюючи з переходом вже на baselevel x86_64-v2 в багатьох дистро - дебіан виглядає дійсно дуже консервативним якщо тільки розпочав i386 дропити

Які моменти з 13го (та софту з нього) для вас були цікаві?
От прикольно що користувачу з інтерфейсу "апп сторе" дають обирати ставити софт як флетпак чи бінарний пакет (і вказують розмір обох видів).

[yvs115]

Пропускаючи скрізь філософські частини "а там у них"), по тех.частині

Гадки не маю про який configure йде мова, якщо це configure з autoconf то це залежить і що там прописано, і також як все це далі використовується включно з можливою декларацією через Makefile.

Чому вас здивувало що в сорцах програми можуть бути #ifdef що вимикають частки коду відповідно до змінних з конфігуре (тестів системи та вибору користувача до початку компіляції)?

Якщо мова йде відносно autotools: відпрацьовують зазвичай дві частини згенеровані на базі configure.ac та Makefile.am.
за допомогою configure зазвичай генерується config.h з макро definitions які можуть бути використані для препроцесора для подальшої умовної компіляції частин коду з C sources. Для виключення цілком файлів/директорій використовуються (зновуж зазвичай) умовні if в Makefile[.am] (який також може бути використаний і для інших задач - нп conditional генерації якихось частин в manual pages, etc.). При конфігуруванні можливі варіанти з автоматичним виставленням якихось значень, абож стоп з помилкою якщо якась умов не виконана.
З більш сучасними build systems як нп cmake чи нп meson - все це зведено разом і зручніше, хоча в принципі ідеї такісамі (в деяких пакаджах у мене нп досі зберігаються файли для трьох варіантів побудови з - (1) meson [preferable], (2) cmake, (3) autotools [least preferable]. Якщо не про C - то в багатьох мовах програмування використовуються свої proper build systems - які зазвичай доволі відрізняються від autotools/cmake/meson підходів і тому їх треба розглядати окремо.

Але я запитував про пакетні менеджери та системи керування софтом загалом

загалом пакетні менеджери не розглядаються в цьому аспекті, бо якщо нп з ports/pkgsrc опції для побудови можна виставити в make.conf/mk.conf, то з deb генерацією то нп через відповідний env змінні та багато інших варіантів, з rpm відрізняєтьтся, з apkbuild/pkgbuild відрізняється, flatpak/snap також по іншому, - я б сказав що опцій варіацій та підходів генерації пакетів існують більш навіть ніж хотілосяби)

Якщо конкретика цікавить - спробуйте саме ті що цікавлять package-managers чи build-systems (а також роботу з бінарними пакаджами в bsd, так і роботу з сирцями в лінуксах) - тоді все то не так філософські виглядати буде.

обирати ставити софт як флетпак чи бінарний пакет

гадки не маю що то значить протиставлення "флетпак чи бінарний пакет", але до debian відношення не проглядується)