Конфиги в /usr?!

Ёрш их через полено, скажите мне, что это просто ошибка сборщика пакета, и на самом деле kde не хранит конфиги в /usr!

А что здесь не так? /usr/share/ как раз и предназначен для всякого контента и прочей хрени. По твоему в хомяк образцы конфигов должны качаться из интернета;)

Это не образцы конфигов. Это ДЕЙСТВУЮЩИЙ конфиг.

locate — это какой-то хитрый алиас для find?

Это не образцы конфигов. Это ДЕЙСТВУЮЩИЙ конфиг.

А если текстовой конфиг скомпилять в разделяемую библиотеку тебе легче станет?

Еще один не знаком с man hier и FHS...

А в нормальных дистрах всё OK!

user@host:~$locate kdmrc
/etc/kde4/kdm/kdmrc
/usr/share/doc/kde/HTML/en/kdm/kdmrc-ref.docbook

Действующие конфиги должны лежать в /etc

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

C:\Program Files специально для тебя

Еще один не знаком с man hier и FHS...

      /usr/share
              This directory contains subdirectories with specific application
              data,  that  can  be shared among different architectures of the
              same OS.  Often one finds  stuff  here  that  used  to  live  in
              /usr/doc or /usr/lib or /usr/man.

specific application data

Только в xml можно хранить данные приложения, в конфигах нельзя?

Млять, /usr/share содержит данные, специфичные для приложения, а не для хоста.

Увы, но конфиг в /usr не считается дефолтным самими кедами. Иначе бы он не правил его при изменении настроек KDM в SystemSettings, а как раз бы создал новый в /etc

Иначе бы он не правил его при изменении настроек KDM в SystemSettings

OMG, кедописатели в своём репертуаре.

Зачем ты исправил файл в /usr/share?

Его само КДЕ правит (в арче, но у них софт почти ванильный, так что с вероятностью в 95% это поведение ванильных кед), если меняешь настройки KDM в их центре настроек.

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

Угу, по упоротости неизвестно ещё кто кого победит: они гномеров или гномеры их. Надо будет ещё в арчике проверить какой файл они будут править, если сделать копию этого конфига в /etc. Совсем смешно станет если даже в такой раскладе они станут работать именно с /usr

Слушай, напильник четырехзвездочный, ты слышал когда-нибудь, что в нормальных системах, таких как GNU/linux, данные принято разделять на per-application, per-host, и per-user? Или этот тупак никогда не закончится?

Двухзвёздочник, от лишних конфигов сваленных в /etc у приложений случается тупак и глюки. Если по стандарту приложения должны глючить, то нужно пропатчить стандарт.

Рядом с гномерами они просто пай-мальчики -_-

от лишних конфигов сваленных в /etc у приложений случается тупак и глюки

все чудесатее и чудесатее

все чудесатее и чудесатее

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

у тебя какая-то каша в голове

Если десять разных настроек и разных наборов плагинов для одного приложения, то ни в /etc ни в /usr им делать нечего совершенно одинаково. Потому что и то, и то - места для _системных_ вещей, причем первое для изменяемых, а второе для статических.

FHS устарела, теперь в моде бардак.

Если десять разных настроек и разных наборов плагинов для одного приложения

Ни для одного приложения а для 10 приложений. Некоторые плагины не вбрасываются отдельным файлом а вкомпиливаются в бинарник, так надёжнее - несовместимости выявляются уже на этапе компиляции.

Потому что и то, и то - места для _системных_ вещей

Компиляторы и среды разработки отличные от gcc, это как раз системные вещи.

причем первое для изменяемых, а второе для статических.

И как отличать изменяемое от статического? На нём штампа «статическое» не стоит. Если нужно пересобрать бинарник находящийся в /usr/share то он как раз получится изменяемым)))))))) Естественно, заглушка в /usr/bin останется статической.

Компиляторы и среды разработки отличные от gcc, это как раз системные вещи.

Осиль параметр --sysconfdir в опциях сборки.

И как отличать изменяемое от статического?

Нужно отличать не изменяемое от статического, а данные ХОСТА от данных ПРИЛОЖЕНИЯ. Данные ПРИЛОЖЕНИЯ зависят от сорцов и опций компиляции оного приложения. И больше ни от чего.

Осиль параметр --sysconfdir в опциях сборки.

Нет такой штуки, ты что-то не то советуешь.

Данные ПРИЛОЖЕНИЯ зависят от сорцов и опций компиляции оного приложения. И больше ни от чего.

То есть всё же нужно каждый раз лезть в исходники и всё там править чтобы получилось так, как нужно товарищу geekless? Если же приложение собирается коммандой make all +опции, то ничего без бубна туда своего не добавишь - как собралось, тому и радуйся.

Нет такой штуки

 ./configure --help | grep sysconfdir
  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]

То есть всё же нужно каждый раз лезть в исходники и всё там править чтобы получилось так, как нужно товарищу geekless? Если же приложение собирается коммандой make all +опции, то ничего без бубна туда своего не добавишь - как собралось, тому и радуйся.

Ты совсем упоротый? Данные, которые зависят от хоста, лежат в /etc. Меняй их сколько хочешь.

./configure --help | grep sysconfdir

--sysconfdir=DIR read-only single-machine data [PREFIX/etc]

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

Ты совсем упоротый? Данные, которые зависят от хоста, лежат в /etc. Меняй их сколько хочешь.

Ты чёто с веществами передозировал, если данные в /etc ни на что не влияют, то и класть их туда не обязательно. Или можно положить для плаформы - пусть полежат, авось пригодятся.

не всем охота возиться с её подключением и бяками.

Это единственный способ. Другой вариант — астрал. Но сам понимаешь, с астралом будут проблемы.

Ты чёто с веществами передозировал, если данные в /etc ни на что не влияют, то и класть их туда не обязательно. Или можно положить для плаформы - пусть полежат, авось пригодятся.

Молодой (?) человек, вы тяжело больны, либо чем-то упороты. Данные ПРИЛОЖЕНИЯ — это то, как всё сделал и настроил разработчик ПО и сборщик пакета. А данные ХОСТА — это как настроил админ данного хоста.

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

Это единственный способ. Другой вариант — астрал. Но сам понимаешь, с астралом будут проблемы.

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

Данные ПРИЛОЖЕНИЯ — это то, как всё сделал и настроил разработчик ПО и сборщик пакета. А данные ХОСТА — это как настроил админ данного хоста.

По твоим словам выходит что пакеты в /etc ничего не кладут, этим только админ должен заниматься. Интересно, какой дистрибутив так устроен?

По твоим словам выходит что пакеты в /etc ничего не кладут, этим только админ должен заниматься.

В /etc кладут ФАЙЛЫ ПРЕДНАЗНАЧЕННЫЕ ДЛЯ ПРАВКИ АДМИНОМ.

В /etc кладут ФАЙЛЫ ПРЕДНАЗНАЧЕННЫЕ ДЛЯ ПРАВКИ АДМИНОМ.

Несколько пакетов разных версий положат туда по файлику с одинаковым именем и потрут всё что админ поправил и будут конфиктовать. Конечно, конфиги типа fstab пакеты не меняют, но это как раз как бы и намекает - не кладите в /etc ничего лишнего, используйте /usr/share/приложение которым ты так недоволен.

Несколько пакетов разных версий

Ты просто не сможешь установить пакетов разных версий.

потрут всё что админ поправил

В стране напильников еще не вкурсе, что пакетные менеджеры не перезаписывают конфигурационные файлы в /etc при установке и обновлении пакетов?

используйте /usr/share/приложение

Расскажи мне, о великий, чем же /usr/share/приложение так магически отличается от /etc/приложение? Может потусторонняя /usr/share/приложение своя для каждой версии приложения? Нет, не своя. Облом, облом...

Ты просто не сможешь установить пакетов разных версий.

Уже установлены - rpm куда им хочется, куча *.tar.gz в хомяк и *.exe в вайн до кучи. Если всерьёз буду использовать дополнительные расширения гуёвой среды разработки, то её тоже придётся ставить в хомяк чтобы новые версии всё не порушили.

В стране напильников еще не вкурсе, что пакетные менеджеры не перезаписывают конфигурационные файлы в /etc при установке и обновлении пакетов?

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

Расскажи мне, о великий, чем же /usr/share/приложение так магически отличается от /etc/приложение?

Если приложение не разбрасывает сопли по системе и хранит всё кроме заглушек и ярлыков в своём каталоге, то почему оно должно ломать свою архитектуру ради того чтобы покакать в /etc/ ?

Может потусторонняя /usr/share/приложение своя для каждой версии приложения? Нет, не своя. Облом, облом...

У kde3 и kde4 разные каталоги и другим приложения так делать не запретишь.

У kde3 и kde4 разные каталоги и другим приложения так делать не запретишь.

А в /etc использовать разные каталоги религия запрещает?

А в /etc использовать разные каталоги религия запрещает?

А для чего обязательно распылять упитанное приложение по системе?

Для удобства администрирования и обсуживания.

Всё знать нельзя, скорее всего ты будешь администрировать незнакомое приложение наобум, находя знакомые слова в тексте. А если захочешь всерьёз ознакомиться с приложением, то расположение всей машинерии в одном родительском каталоге более удобно. Кроме того, приложение хранящее свои конфиги у себя, удобнее запускать с внешнего носителя воткнутого в систему. Пришёл на рабочий/учебный комп, воткнул флешку и работай/играй, следов не останется.

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

А я все ждал причину отправки geekless в игнор. И вот она!

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

Ты удивишься, если узнаешь сколько всего хранит конфиги в /usr?

Компиляторы и среды разработки отличные от gcc, это как раз системные вещи.

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

Если нужно пересобрать бинарник находящийся в /usr/share

use-case, пожалуйста. Бинарные файлы в /usr/share, которые надо пересобирать - это что-то из ряда вон.

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

1. Какая наивность... Может я его из пропатченных исходников соберу и в систему установлю;) Если компилятор не называется gcc, то делай что хочешь, система не рухнет.

2. Компиляторам нужно находить пути к своим и системным либам/модулям а также всякой бинарщине и они это делают даже если в /etc/конфиг прописана лажа.

use-case, пожалуйста.

По русски пожалуйста.

Бинарные файлы в /usr/share, которые надо пересобирать - это что-то из ряда вон.

Это опенсорс. Если всегда есть исходники и вся среда разработки со всеми батарейками собрана одним компилятором, то этим надо пользоваться и без необходимости не тащить в систему разделяемое бинарьё собранное другим компилятором. Поэтому в лазарусе все устанавливаемые в него дополнительные компоненты прикомпиливаются к бинарнику: будь то нестандартная хреновина для клепания окошек или игровой движок - всё пересобирается родным компилятором почти как в генте. Компиляция быстрая, поэтому если сделать бекап рабочего бинаря то не страшно. В проприетарной дельфи, наоборот, можно ставить уже кем-то собранные готовые компоненты, на то она и проприетарная.

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

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

каким образом у тебя то, что собирает юзер из исходников, когда ему втемяшится связано с системными пакетами?

Сначала ставятся пакеты: компилятор со своими модулями, среда разработки со своими модулями, их исходники. Там есть почти всё необходимое, но если тебе потребуется добавить новый компонент, тогда добавляешь новые исходники и пересобираешь что тебе нужно. Также можно пересобрать на Gt гуёвину среды разработки собранную по умолчанию на GTK2.

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

Стараюсь вписывать свои потребности в возможности поставляемых компонентов, но иногда их не хватает и тогда да, приходится пересобирать. (иногда также переименовываю пакетные mplayer и mencoder и ставлю поверх свои, собранные по другому) Из под рута пересобирать неудобно - используются данные из личного каталога пользователя root а надо простого юзверя который постоянно использует эту программу, потому лучше поменять права на каталог и компилять из под него.

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

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

но иногда их не хватает и тогда да, приходится пересобирать.

Пересобирать никто не запрещает. Пересборка каких-то компонентов под свои нужны - это нормально, но либо пересобранное(если это пользовательское приложение) идет в /home, либо (если этим должны пользоваться несколько пользователей) в /opt(/usr/local), либо (в идеале) заворачивается в пакет.

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

Злостный ССЗБ.

ЧЯДНТ?

alex-p@slon ~ $ locate kdmrc
/etc/kde/kdm/kdmrc

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

А как же самомодификация приложения? Кто-то говорит «низзя» и запрещает технологию.

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