/etc/os-release — всё :)

А если гентушник захочет с помощью серии четко выверенных действий превратить живую генту в Fedora? :)

а-то ведь не хотят systemd использовать для embeded . а разработчики systemd — очень хотят наверное.

А я её видел на какой-то китайщине

/var/lib не?

А если гентушник захочет с помощью серии четко выверенных действий превратить живую генту в Fedora? :)

А гентушник может такое захотеть? :)

То он поменяет файл в /usr/lib, очевидно.

/etc/os-release — всё :) (комментарий), /var — тоже непостоянное хранилище.

/etc не очень подходит

http://www.merriam-webster.com/dictionary/etcetera

Ты ещё скажи, что /usr должен содержать пользовательские данные, bin бинарники (никаких скриптов!), а var изменяющиеся данные (только попробуй туда положить файл, который не будет меняться).

/usr должен содержать пользовательские данные

Ты удивишься, но usr — это UNIX System Resources.

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

Отлично, значит линуксовых данных там не должно быть. Он ведь не юникс.

/var — тоже непостоянное хранилище.

/var - хранилище изменяемой системной инфы, все изменяемые данные софта не относящиеся к пользователю

Про os-release - да, затупил наверное, скорее тогда /usr/share как {редко,не}изменяемым данные

Я же тебе сказал, почему можно.

По законам физики можно. Но де-факто в /etc сейчас лежат конфиги.

вот почему поттеринг лезет в /usr/lib? os-release, видимо, библиотека (как и сервисы systemd, ага)? если уж так хочется запихнуть os-release в /usr, надо в /usr/share.

Ну, в общем, идея уловлена верно. Лайвы и прочие параноидальные конфигурации с жестко разделенным persistent storage, который никак не влияет на сквошный (в идеале - валяющийся на защищенном носителе) образ корневой ФС. В простейшем случае persistent storage может вырождаться в единственный файлик с параметрами для загрузчика, вот там-то фокусы с /proc/cmdline могут пригодиться.

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

Весьма показательно, как сторонники открытой разработки относятся к... открытой разработке.

Само название /etc весьма способствует размещению там файла os-release, ящитаю.

Ну, тут из джаббера передают:

весь этот треш для stateless-систем

Поцтерингу в один момент кольнуло, и он захотел, чтобы система работала и с пустым /etc. А дефолтные настройки хранить в /usr

это же кстате — классно

вы прям с derlafff — одновременно :) .. хы :)

Само название /etc весьма способствует размещению там файла os-release, ящитаю.

дааа.. это верно(!) с названием «etc» — явно что-то не так. :)

но если переименовать «etc» в «conf» — то будет как всё равно какой-то говномакинтош эпполовский (вобщем не круто).

cat /etc/SuSE-release
openSUSE 13.1 (i586)
VERSION = 13.1
CODENAME = Bottle
# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead

а там нет файла /usr/lib/SuSE-release в котором было бы напичанно что-то типа /usr/lib/SuSE-release is deprecated and will be removed in the future, use /usr/lib/os-release instead ? :-)

а-то я тут анекдот вспомнил:

-- Чем отличается пÓртфель от портфÉля?
-- Хм. Раз плюнуть: в пÓртфель кладу! докÝменты, а в
портфÉль -- докумÉнты.

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

лет через 10 сделают /usr -> /

он в черепные коробочки разработчиков походу проникает периодически, нафиг не нужна такая свежесть.

не проникает, а свободно циркулирует

Не сделают. Они отдельный /usr явно считают фичей.

Если переименовать в conf, то это будет вообще некошерно и на тебя будут смотреть, как на говно — мол, не следуешь никсовым стандартам.

Если есть возражения, напиши в systemd-devel.

Дело в том, что /usr/lib — это архитектура-зависимые файлы. И юниты, и os-release потенциально отличаются для разных архитектур.

Штеудач, /usr/lib - это архитектурозависимые библиотеки. Туда ну никак os-release не вписывается. При болгенинге арча для сборки асгарда я чуток подзавалил лицо оттого, что всё-таки пришлось пилить перемещение os-release не в самом оверлее, а уже в customize_root_imairootfs.sh, иначе никак. Где логика помещения инфы о дистрибутиве рядом с библиотеками?

systemd вслед за debian-ом считает, что $libdir — это /usr/lib/<идентификатор архитектуры>, а /usr/lib — всего лишь

Static, private vendor data that is compatible with all architectures (though not necessarily architecture-independent)".

Это file-hierarchy(7).

Кстати, а почему оверлей не срабатывает?

А теперь сделай ls /usr/lib, подожди, пока всю простыню выведет, и добро пожаловать в реальный мир - имело в виду большинство приложений этот <идентификатор архитектуры>. Его вообще хоть кто-нибудь, кроме gcc и Qt, использует?

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

Ну блин, новый стандарт же. Там /usr/lib (и /usr/lib64) указаны как «Legacy locations».

Насколько я мог понять из постов в systemd-devel, в Debian multiarch уже давно сделан именно так.

сделай ls /usr/lib, подожди, пока всю простыню выведет

Это на какой системе после ls ждать надо?

$ time ls -1 /usr/lib64/
<cut>
real    0m0.036s
user    0m0.012s
sys     0m0.014s

$ ls -1 /usr/lib64/| wc -l
2570

$ grep 'model name' /proc/cpuinfo | uniq
model name      : AMD Athlon(tm) II X2 250 Processor

Если у тебя нвидиевский блоб или просто vesafb без ywrap и ты сидишь в VT — то ждать таки надо =)

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

да ладно, его не жалко, туда все, что попало складывают. а вот нарушать девственную чистоту /usr/lib, где лежат исключительно библиотеки (еще модули ядра, да, но будем считать, что они в /lib) нехорошо.

Пусть разрабам over9000 приложений про "новый стандарт" расскажут, а то они не в курсе.

кстати, с чего это os-release архитектурно-зависим?

$ find /usr/lib -mindepth 1 -maxdepth 1 -type f | egrep -v '\.(a|so|la|o)(\.[0-9]*)*'
/usr/lib/apr.exp
/usr/lib/aprutil.exp
/usr/lib/default.sfx
/usr/lib/dirmngr_ldap
/usr/lib/e2initrd_helper
/usr/lib/libQt3Support.prl
/usr/lib/libQt5Bootstrap.prl
/usr/lib/libQt5Concurrent.prl
/usr/lib/libQt5Core.prl
/usr/lib/libQt5DBus.prl
/usr/lib/libQt5Gui.prl
/usr/lib/libQt5Multimedia.prl
/usr/lib/libQt5Network.prl
/usr/lib/libQt5OpenGL.prl
/usr/lib/libQt5Positioning.prl
/usr/lib/libQt5PrintSupport.prl
/usr/lib/libQt5Qml.prl
/usr/lib/libQt5QmlDevTools.prl
/usr/lib/libQt5Quick.prl
/usr/lib/libQt5QuickTest.prl
/usr/lib/libQt5QuickWidgets.prl
/usr/lib/libQt5Sensors.prl
/usr/lib/libQt5Sql.prl
/usr/lib/libQt5Svg.prl
/usr/lib/libQt5Test.prl
/usr/lib/libQt5WebKit.prl
/usr/lib/libQt5WebKitWidgets.prl
/usr/lib/libQt5Widgets.prl
/usr/lib/libQt5Xml.prl
/usr/lib/libQt5XmlPatterns.prl
/usr/lib/libQtCLucene.prl
/usr/lib/libQtCore.prl
/usr/lib/libQtDBus.prl
/usr/lib/libQtDeclarative.prl
/usr/lib/libQtDesigner.prl
/usr/lib/libQtGui.prl
/usr/lib/libQtHelp.prl
/usr/lib/libQtMultimedia.prl
/usr/lib/libQtNetwork.prl
/usr/lib/libQtOpenGL.prl
/usr/lib/libQtScript.prl
/usr/lib/libQtScriptTools.prl
/usr/lib/libQtSql.prl
/usr/lib/libQtSvg.prl
/usr/lib/libQtTest.prl
/usr/lib/libQtUiTools.prl
/usr/lib/libQtWebKit.prl
/usr/lib/libQtXml.prl
/usr/lib/libQtXmlPatterns.prl
/usr/lib/libcilkrts.spec
/usr/lib/libfreebl3.chk
/usr/lib/libgomp.spec
/usr/lib/libitm.spec
/usr/lib/libnssdbm3.chk
/usr/lib/libqca.prl
/usr/lib/libqgsttools_p.prl
/usr/lib/libqoauth.prl
/usr/lib/libsanitizer.spec
/usr/lib/libsoftokn3.chk
/usr/lib/os-release
/usr/lib/qmi-proxy
/usr/lib/tclConfig.sh
/usr/lib/tclooConfig.sh
/usr/lib/tkConfig.sh
/usr/lib/xml2Conf.sh
/usr/lib/xsltConf.sh
/usr/lib/libQt5MultimediaQuick_p.prl
/usr/lib/libQt5MultimediaWidgets.prl
/usr/lib/libQt5OpenGLExtensions.prl
/usr/lib/libQt5PlatformSupport.prl
/usr/lib/libQt5QuickParticles.prl
/usr/lib/libQtAssistantClient.prl
/usr/lib/libQtDesignerComponents.prl
/usr/lib/xf86-video-intel-backlight-helper

Сорри за простыню, но /usr/lib уже давно не девственно чистый. Ну и да, я вроде привёл объективный аргумент к тому, почему так всё же стоит делать.

Разрабы приложений должны уметь в ./configure --libdir, от них больше ничего не требуется. А мейнтейнеры дистрибутивов либо уже знают, либо вскоре узнают — это их работа =)

Там могут быть разные названия для разных архитектур.

Они отдельный /usr явно считают фичей.

отдельный /usr, это когда он на другом носителе, а благодаря их стараниям теперь usr должен валяться там же, где и ведро.

отдельный /usr, это когда он на другом носителе, а благодаря их стараниям теперь usr должен валяться там же, где и ведро.

сам Поттеринг респектировал Gummiboot :)

а Gummiboot подразумевает что ядро находится на FAT32 (/boot/ ,который EFI) . то есть это явно не /usr/ :-)

любовные интриги наркоманов меня мало волнуют :) пусть респектуются где-то подальше от моего линукса

Ты упорот или просто тролль. Нет никаких требований к расположению /usr. Впрочем, всё просто: пруф или GTFO.

ищи поиском systemd и /usr. если ты не в курсе этой истории, то ее краткая суть такова, что с переносом всего в /usr минимально загружающаяся система теперь содержит в себе весь жир, либо требует запихивания бывших /{s}bin и /lib в initrd. про ведро я не совсем корректно сказал. любители экспериментов негодуют. хомякам похрен.

Я прекрасно знаю, как работает systemd и как это соотносится с /usr на отдельном разделе. Такая конфигурация требует наличия initramfs (что правильно), но ты говорил не об этом.

с переносом всего в /usr минимально загружающаяся система теперь содержит в себе весь жир, либо требует запихивания бывших /{s}bin и /lib в initrd

Прекрати пороть чушь, ей больно.

не мешай нам с ней развлекаться! :)