Да, я знаю зачем она существует. Но считаю что она нинужна в 2к17, а вендоры, которые упаковывают свой софт, уповая на то что он будет сложен в /opt, должны получать лучи поноса в лицо от сообщества :3

вот тут прям не соглашусь. Альтернативы?

(вообще мне кажется что если перестать использовать всякую джавню то в /opt никакого говна не будет вообще)

(вообще мне кажется что если перестать использовать всякую джавню то в /opt никакого говна не будет вообще)

и опять не соглашусь: 1. Там будет еще много чего. 2. Джавню использовать можно и нужно. Для своих задач - вещь.

вот тут прям не соглашусь. Альтернативы?

Альтернативы? Делать софт таргетированно под линукс. Ну или перепаковывать, вот например как я кафку по полочкам раскладываю https://github.com/corpix/kafka-container/blob/master/kafka/prepare.sh

и опять не соглашусь: 1. Там будет еще много чего. 2. Джавню использовать можно и нужно. Для своих задач - вещь.

А что там ещё будет? Я помимо джавни ничего в /opt не видел

Ну вы жжоте коты

Утро субботки, чё бы не похоливарить? :D

А что там ещё будет? Я помимо джавни ничего в /opt не видел

ну вот, к слову, лучи поноса разработчикам Go пошли, например. Он отлично в /opt ложится. Как там и лежал. И клал Go на весь ваш fhs, например

Еще в /opt традиционно Qt ложится.

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

Ну вы жжоте коты

это мы еще не начинали) так, разминаемся... Не каждый же день о дженериках)

ну вот, к слову, лучи поноса разработчикам Go пошли, например. Он отлично в /opt ложится. Как там и лежал. И клал Go на весь ваш fhs, например

Да, я им давно, ещё за реализацию некоторых типов в стандартной библиотеке про крипту, хочу послать несколько лучиков. А ещё за то что вся стандартная либа в errors.New() и fmt.Errorf() вместо того чтобы выделить отдельные типы под каждую ошибку. Но это ладно. В дистрибутивах он нормально упакован, по человечески

Еще в /opt традиционно Qt ложится.

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

Да, я им давно, ещё за реализацию некоторых типов в стандартной библиотеке про крипту, хочу послать несколько лучиков. А ещё за то что вся стандартная либа в errors.New() и fmt.Errorf() вместо того чтобы выделить отдельные типы под каждую ошибку. Но это ладно. В дистрибутивах он нормально упакован, по человечески

ну вот, собственно, что такое /opt. Предполагается, что конечный разработчик унутре своего каталожега в /opt организует совершенно стандартную иерархию. Ровно такую, как лежит в /, в /usr и в /usr/local

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

"Все должно быть из пакетов" - дорога в никуда.

Короче, я не понимаю принципиального различия между /, /usr, /usr/local и /opt/vendorname. Ровно одно и то же, просто сложено в разных местах.

ну вот, собственно, что такое /opt. Предполагается, что конечный разработчик унутре своего каталожега в /opt организует совершенно стандартную иерархию. Ровно такую, как лежит в /, в /usr и в /usr/local

Я так в /home/%username% делаю, нет нужды ставить что-то от супер-пользователя в какой-то левый каталог, когда можно локально, прямо в своей домашней папке сделать несколько префиксов

Я так в /home/%username% делаю, нет нужды ставить что-то от супер-пользователя в какой-то левый каталог, когда можно локально, прямо в своей домашней папке сделать несколько префиксов

вот теперь я вас осуждаю. Без реального обоснования нужности на /home вообще noexec стоять должен.

"Все должно быть из пакетов" - дорога в никуда.

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

Я так в /home/%username% делаю, нет нужды ставить что-то от супер-пользователя в какой-то левый каталог, когда можно локально, прямо в своей домашней папке сделать несколько префиксов

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

Парни, как и где константой хранить такую строку: fmt.Sprintf("amqp://%s:%s@%s:%s", settings.RUSER, settings.RPASSWD, settings.RHOST, settgings.RPORT) чтобы каждый раз не создавать новую строку

вот теперь я вас осуждаю. Без реального обоснования нужности на /home вообще noexec стоять должен.

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

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

Уютно там, в идеальном мире?)))

Парни, как и где константой хранить такую строку: fmt.Sprintf("amqp://%s:%s@%s:%s", settings.RUSER, settings.RPASSWD, settings.RHOST, settgings.RPORT) чтобы каждый раз не создавать новую строку

Одной строкой в конфиге кажется будет проще. Ну или темплейт в конфиге храни

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

Ну вот эти разработчики мейнтейнерам жизнь усложняют на мой взгляд

Парни, как и где константой хранить такую строку: fmt.Sprintf("amqp://%s:%s@%s:%s", settings.RUSER, settings.RPASSWD, settings.RHOST, settgings.RPORT) чтобы каждый раз не создавать новую строку

Как вариант, в переменной окружения... А еще можно var neededString string init() { neededString = whateverYouWant }

Уютно там, в идеальном мире?)))

До идеального мира ещё очень далеко, но мы идёт потихоньку

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

по умолчанию - в чем-нибудь узкоспецифичном. В Андроиде, наверное, например.

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

Ну вот эти разработчики мейнтейнерам жизнь усложняют на мой взгляд

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

по умолчанию - в чем-нибудь узкоспецифичном. В Андроиде, наверное, например.

Возможно. Но я из угроз, которую noexec может предотвратить только 1 припоминаю - подмена PATH и эскалация привилегий засчет этого. Но noexec это только 1 заплатка и полностью проблему не решает. Так что особо смысла в нем не вижу

"Все должно быть из пакетов" - дорога в никуда.

Это дорога в пакетированный рай.

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

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

Возможно. Но я из угроз, которую noexec может предотвратить только 1 припоминаю - подмена PATH и эскалация привилегий засчет этого. Но noexec это только 1 заплатка и полностью проблему не решает. Так что особо смысла в нем не вижу

Проблема должна решаться комплексно, но, допустим, такую вещь, как положить в хомяк скрипт, который делает rm -rf ~/ оно вполне себе побеждает

Это дорога в пакетированный рай.

это дорога к возврату в 0.3% пользователей

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

Да хотя бы тем что надо отдельные policy для selinux/apparmor писать. Ну, это мейнтейнерам. А тем кто это поделие обслуживает нужно запоминать ещё и структуру каталогов, которую там разработчики выдумали

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

собственно, если оно в контейнере крутится, конкретно вам noexec на хомяк не повредит

Проблема должна решаться комплексно, но, допустим, такую вещь, как положить в хомяк скрипт, который делает rm -rf ~/ оно вполне себе побеждает

Ну я могу вместо скрипта отредактировать профиль и сделать алиас, который тоже самое сделает. Так что не решает

собственно, если оно в контейнере крутится, конкретно вам noexec на хомяк не повредит

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

это дорога к возврату в 0.3% пользователей

Если пакетироваться будет как в дебиане то возможно :D А так, rpm'ы собирать совсем не сложно

Кстати про пакеты... вот этот товарищ дело пишет http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

Да хотя бы тем что надо отдельные policy для selinux/apparmor писать. Ну, это мейнтейнерам. А тем кто это поделие обслуживает нужно запоминать ещё и структуру каталогов, которую там разработчики выдумали

Попробуем по порядку: 1. Мейнтейнер один фиг будет писать policy, иначе он не мейнтейнер. 2. Если разработчик вменяемый, нифига запоминать не надо. Есть /opt/vendorname, а унутре - bin, var, etc и прочие так полюбившиеся вам вещи. В том и смысл /opt. 3. Если унутре не fhs - значит, предполагается, что оно не предназначено для опакечивания, и нефиг мейнтейнерам туда лезть.

Ну я могу вместо скрипта отредактировать профиль и сделать алиас, который тоже самое сделает. Так что не решает

элементарные вещи в лоб - решает. Мешать, особливо, не мешает. Чо еще надо?

Попробуем по порядку: 1. Мейнтейнер один фиг будет писать policy, иначе он не мейнтейнер. 2. Если разработчик вменяемый, нифига запоминать не надо. Есть /opt/vendorname, а унутре - bin, var, etc и прочие так полюбившиеся вам вещи. В том и смысл /opt. 3. Если унутре не fhs - значит, предполагается, что оно не предназначено для опакечивания, и нефиг мейнтейнерам туда лезть.

Не консистентно это, раздражает. Нужна одна структура, которой все будут придерживаться

Если пакетироваться будет как в дебиане то возможно :D А так, rpm'ы собирать совсем не сложно

Вот какбэ вы головняк мейнтейнеров сейчас на разработчика переложить попытались. Низачот.

Попробуем по порядку: 1. Мейнтейнер один фиг будет писать policy, иначе он не мейнтейнер. 2. Если разработчик вменяемый, нифига запоминать не надо. Есть /opt/vendorname, а унутре - bin, var, etc и прочие так полюбившиеся вам вещи. В том и смысл /opt. 3. Если унутре не fhs - значит, предполагается, что оно не предназначено для опакечивания, и нефиг мейнтейнерам туда лезть.

И к пункту 1 добавлю, мейнтейнеру policy придётся писать в любом случае, да. Но там будет больше копипасты и правил, чем могло бы быть

Не консистентно это, раздражает. Нужна одна структура, которой все будут придерживаться

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

Не консистентно это, раздражает. Нужна одна структура, которой все будут придерживаться

На рынке 13 разных стандартов. О боже! Нужен единый стандарт...

Вот какбэ вы головняк мейнтейнеров сейчас на разработчика переложить попытались. Низачот.

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

И, собственно, что там внутри /opt/vendor - головняк вендора. Не нравится - удали.

На рынке 13 разных стандартов. О боже! Нужен единый стандарт...

Он есть уже, просто не все его придерживаются

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

Вот полностью согласен. Годами сложилось и очень удобно.

И к пункту 1 добавлю, мейнтейнеру policy придётся писать в любом случае, да. Но там будет больше копипасты и правил, чем могло бы быть

Дык, срать на мейнтейнера. Если приложение - пакет дистрибутива, мейнтейнер положит его в /usr, и напишет ровно одни полиси для ровно одного случая. Если кто-то хочет то же самое поставить руками в /opt - это НЕ головняк мейнтейнера, пусть тот, кто ставит, полиси и пишет. Мейнтейнер сопровождает ровно один кейс - тот, который считает единственно правильным.

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

Ну мы вернулись к тому, с чего начали)))

Он есть уже, просто не все его придерживаются

Это вы про всякие hpux, солярисы и фрибсд? В юниксах исторически настолько много было всяких вариаций, что вот эти /usr, /usr/local, /opt есть манна небесная уже

Дык, срать на мейнтейнера. Если приложение - пакет дистрибутива, мейнтейнер положит его в /usr, и напишет ровно одни полиси для ровно одного случая. Если кто-то хочет то же самое поставить руками в /opt - это НЕ головняк мейнтейнера, пусть тот, кто ставит, полиси и пишет. Мейнтейнер сопровождает ровно один кейс - тот, который считает единственно правильным.

Тк мейнтейнеру тогда перепаковывать надо. А вот взять туже кафку, например, там когда начинаешь её скрипты растаскивать такой пиздец начинается, что патчить надо https://github.com/corpix/kafka-container/blob/master/kafka/prepare.patch

Это вы про всякие hpux, солярисы и фрибсд? В юниксах исторически настолько много было всяких вариаций, что вот эти /usr, /usr/local, /opt есть манна небесная уже

Не, их можно считать мёртвыми)))

В /opt например идет очень много бинарного проприетарного говна. Лучше оно пусть живет там, чем разбросано по всей системе.

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

Мейнтейнер - это такой человек, который: а) сопровождает 1 дистрибутив б) следит за политикой этого дистрибутива в) в теории, значет, что делает г) является "заслоном" между недобросовестным разработчиком и конечным поьзователем. Т.е. он НЕ ДОЛЖЕН доверять полиси, написанным разработчиком. Он их один хрен сам родить должен для своего конкретного окружения. Иначе говно он, а не мейнтейнер. Разработчик же НЕ ДОЛЖЕН изучать причуды в политике 152 разрозненных дистрибутивов и писать разветвленные деревья полисей на каждый возможный случай. Мейнтейнер один хрен это (в идеале) лучше сделает.

Мейнтейнер - это такой человек, который: а) сопровождает 1 дистрибутив б) следит за политикой этого дистрибутива в) в теории, значет, что делает г) является "заслоном" между недобросовестным разработчиком и конечным поьзователем. Т.е. он НЕ ДОЛЖЕН доверять полиси, написанным разработчиком. Он их один хрен сам родить должен для своего конкретного окружения. Иначе говно он, а не мейнтейнер. Разработчик же НЕ ДОЛЖЕН изучать причуды в политике 152 разрозненных дистрибутивов и писать разветвленные деревья полисей на каждый возможный случай. Мейнтейнер один хрен это (в идеале) лучше сделает.

Да, мейнтейнер и напишет полиси. Но, в системах есть базовые полиси для /etc, например, которые мейнтейнеру придётся повторить для /opt/some-shit-software/etc и т.д.

Тк мейнтейнеру тогда перепаковывать надо. А вот взять туже кафку, например, там когда начинаешь её скрипты растаскивать такой пиздец начинается, что патчить надо https://github.com/corpix/kafka-container/blob/master/kafka/prepare.patch

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

И каждый дистрибутив патчит, пересобирает :)

Куча человекочасов в помойку

В /opt например идет очень много бинарного проприетарного говна. Лучше оно пусть живет там, чем разбросано по всей системе.

Вот тут согласен. И это проприетарное говно, раз оно там уже появилось, вероятно, почему-то нужно. Так что пусть лучше оно в опте лежит и за пределы оного не растекается.

Да, мейнтейнер и напишет полиси. Но, в системах есть базовые полиси для /etc, например, которые мейнтейнеру придётся повторить для /opt/some-shit-software/etc и т.д.

у вас какие-то странные представления о мейнтейнере. Вот есть базовые полиси - они для того, что в /usr. Согласен, это работа мейнтейнера. Вот есть /opt, куда складывают все, что ни попадя. Вот тут уже НЕ работа мейнтейнера. Сложил - разруливай. Не хочешь разруливать - удали.

Ну хз, проприетарное бинарное говно может и пакетами распространяться, лежа рядом с другим бинарным неговном из пакетов. На сегодняшний день иметь репозиторий на каком-нибудь suse OBS или fedora copr не сложно. Зато всё можно уложить в предсказуемую иерархию и в пакет

Мейнтейнер не должен для ?opt полиси писать

Ну хз, проприетарное бинарное говно может и пакетами распространяться, лежа рядом с другим бинарным неговном из пакетов. На сегодняшний день иметь репозиторий на каком-нибудь suse OBS или fedora copr не сложно. Зато всё можно уложить в предсказуемую иерархию и в пакет

Вот нафига?

Может-то оно может распространяться. В идеальном мире...

Ну хз, проприетарное бинарное говно может и пакетами распространяться, лежа рядом с другим бинарным неговном из пакетов. На сегодняшний день иметь репозиторий на каком-нибудь suse OBS или fedora copr не сложно. Зато всё можно уложить в предсказуемую иерархию и в пакет

Не может. Имеем диллему шерифа и индейцев.

у вас какие-то странные представления о мейнтейнере. Вот есть базовые полиси - они для того, что в /usr. Согласен, это работа мейнтейнера. Вот есть /opt, куда складывают все, что ни попадя. Вот тут уже НЕ работа мейнтейнера. Сложил - разруливай. Не хочешь разруливать - удали.

А мы сейчас про какие полиси говорим? Я говорил про selinux/apparmor policy, т.е. правила для контроля доступа и безопасности

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

Не может. Имеем диллему шерифа и индейцев.

Что это за диллема? Я не в курсе

А мы сейчас про какие полиси говорим? Я говорил про selinux/apparmor policy, т.е. правила для контроля доступа и безопасности

Порежь все по максимуму из /opt/*

Что это за диллема? Я не в курсе

Проблемы индейцев шерифа не кузюкают

Хех

А мы сейчас про какие полиси говорим? Я говорил про selinux/apparmor policy, т.е. правила для контроля доступа и безопасности

Отрежь все. Если кому-то что-то нужное отрезало полисями - пусть ручками даст права. Не хочет разбираться - не так оно ему нужно. Все, тут вопрос решен? Переходим к варианту все-в-пакет?

Отрежь все. Если кому-то что-то нужное отрезало полисями - пусть ручками даст права. Не хочет разбираться - не так оно ему нужно. Все, тут вопрос решен? Переходим к варианту все-в-пакет?

Не согласен с этой точкой зрения, но спорить дальше не хочу))

Так что поехали дальше

Окей, поехали дальше. Все опакечиваем.

Т.е. бабушка-с-линуксом поднимает себе репозиторий с нужными ей пакетами, добавляет репку и ставит оттуда. Реально???)))

Или это разработчик софтины должен поднять репку для федоры 22,23,24,25,26, для suse, для debian 6,7,8,9, для убунты 12.04,14,04,16,04 - и это еще по минимуму, оттестить все кейсы, отловить все баги и конфликты на адресуемых системах, чтобы получить письмо от "благодарного пользователя" с содержанием "Говно твой софт, у меня на минте не завелось" или "А где е-билды, мля?"

Т.е. бабушка-с-линуксом поднимает себе репозиторий с нужными ей пакетами, добавляет репку и ставит оттуда. Реально???)))

Нет, погодите. Есть разработчик, который пилит какой-то проприетарный софт. Его компания поднимает репозиторий(или просто использует suse OBS), в своём контуре собирает бинарники для своего софта, пакетирует их, доставляет в репозиторий. Потом пользователь добавляет себе в конфигурацию пакетного менеджера новый репозиторий и ставит софт. Я вот так это вижу

Или это разработчик софтины должен поднять репку для федоры 22,23,24,25,26, для suse, для debian 6,7,8,9, для убунты 12.04,14,04,16,04 - и это еще по минимуму, оттестить все кейсы, отловить все баги и конфликты на адресуемых системах, чтобы получить письмо от "благодарного пользователя" с содержанием "Говно твой софт, у меня на минте не завелось" или "А где е-билды, мля?"

Он может использовать OBS :) Но если он вдруг его не хочет использовать, то да, он может поднять вебсервер и сгенерить репозиторий в докруте

коллеги, вы ошиблись чатом :)

Нет, погодите. Есть разработчик, который пилит какой-то проприетарный софт. Его компания поднимает репозиторий(или просто использует suse OBS), в своём контуре собирает бинарники для своего софта, пакетирует их, доставляет в репозиторий. Потом пользователь добавляет себе в конфигурацию пакетного менеджера новый репозиторий и ставит софт. Я вот так это вижу

Нюансы уточним: 1. Пакетирует под какие дистрибутивы? 2. Под какие дистрибутивы держать репозитории?

Он может использовать OBS :) Но если он вдруг его не хочет использовать, то да, он может поднять вебсервер и сгенерить репозиторий в докруте

Осталось понять: 1. Зачем? 2. Как это окупать?

Нюансы уточним: 1. Пакетирует под какие дистрибутивы? 2. Под какие дистрибутивы держать репозитории?

Хотя бы под ubuntu && fedora, чтоб получить deb && rpm(которые в теории могут быть и в другие дистры установлены/портированы людьми). Пакетировать это конечно сложнее, чем просто свалить всё в /opt, но всёже - порядка сильно больше.

Осталось понять: 1. Зачем? 2. Как это окупать?

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

Хотя бы под ubuntu && fedora, чтоб получить deb && rpm(которые в теории могут быть и в другие дистры установлены/портированы людьми). Пакетировать это конечно сложнее, чем просто свалить всё в /opt, но всёже - порядка сильно больше.

Ключевое слово "в теории" могут быть установлены. В реальности все веселее, как доктор говорю. На практике, если опакечивать будет мейнтейнер, ему удобнее иметь набор исходников или дерево каталогов с бинарями. Он уже опакетит. Нахрена ему сначала распаковать, а потом упаковывать обратно? В том и фишка, что конкретно в /opt никто и не сваливает. Разработчик говорит: вот есть корень, относительно него путь к либам - lib, к конфигам - etc. А уж что будет корнем - головняк получателя софта. И это, в данном случае, верно.

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

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

А еще этому самому проприетарному говнописателю понадобилась библиоткеа x версии 2.7.168b345 с его лично патчами. И мейнтейнер дистрибутива его совершенно обоснованно лесом послал, отказавшись ее в дистриб тащить.

А в /opt она никому не мешает.

И, по секрету, нет никакого софта, написанного, чтобы лежать в /opt

Есть только софт в зашитыми намертно абсолютными путями, и есть софт, с зашитыми намертво относительными путями.

Если пути относительные - срать на то, где оно лежит. Распакуй вместо /opt в /usr/local или тупо в /usr - ничего не изменится. Будет ровно так же работать.

Если абсолютные - это либо узкосистемный софт, либо разработчик-гомосек.

Ключевое слово "в теории" могут быть установлены. В реальности все веселее, как доктор говорю. На практике, если опакечивать будет мейнтейнер, ему удобнее иметь набор исходников или дерево каталогов с бинарями. Он уже опакетит. Нахрена ему сначала распаковать, а потом упаковывать обратно? В том и фишка, что конкретно в /opt никто и не сваливает. Разработчик говорит: вот есть корень, относительно него путь к либам - lib, к конфигам - etc. А уж что будет корнем - головняк получателя софта. И это, в данном случае, верно.

Если в этой цепочке есть исходники и мейнтейнер, то возможно ему будет удобнее самому это сделать, да. Задача разработчика только исходники подготовить так чтобы было не больно их либо распихать по /etc, /usr/bin, ... в крайнем случае сложить в /opt, но из пакета. Но в любом случае, когда есть "исходники пакета"(например .spec для rpm) мейнтейнеру будет сильно проще понять дивный внутренний мир программы, которую он упаковывает.

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

Под сообществом я имел в виду пользователей