LINUX.ORG.RU
ФорумTalks

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

 ,


0

3

вобщем, тема не совсем технического характера.. но всё равно напишу..

короче, ребята, дело такое — смотрю я на файл /etc/os-release (символьная ссылка на ../usr/lib/os-release)

а он такой одинокий...

...и вдруг вижу:

$ pacman -Qo /etc/os-release
error: No package owns /etc/os-release

удивился очень, однако!

однако поставил arch-install-scripts, сделал pacstrap внутрь /dev/loop0 — и вправду — нету файла /etc/os-release!

такие дела... прям чудеса!

а случилось это вот тут — [commit:6655365]

и ведь и вправду отказывается что Freedesktop — [не заставляет] нас этот файл иметь внутри /etc/

/usr/lib/os-release is the recommended place to store OS release information as part of vendor trees

★★★★★

Последнее исправление: user_id_68054 (всего исправлений: 1)

Ответ на: комментарий от user_id_68054

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

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

Stil ★★★★★
()
Ответ на: комментарий от stevejobs

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

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

Stil ★★★★★
()
Ответ на: комментарий от buddhist

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

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

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

buddhist ★★★★★
()
Последнее исправление: buddhist (всего исправлений: 1)
Ответ на: комментарий от buddhist

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

vurdalak ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

Stil ★★★★★
()
Ответ на: комментарий от buddhist

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

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

vurdalak ★★★★★
()

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

Lincor
()
Ответ на: комментарий от user_id_68054

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

border-radius
()
Ответ на: комментарий от Valkeru

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

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

Alsvartr ★★★★★
()
Ответ на: комментарий от derlafff

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

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

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

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

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от brotheroftux

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

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

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

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от HunOL

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 ? :-)

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

-- Чем отличается пÓртфель от портфÉля?
-- Хм. Раз плюнуть: в пÓртфель кладу! докÝменты, а в
портфÉль -- докумÉнты.
user_id_68054 ★★★★★
() автор топика
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от false

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

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

der_looser ★★
()
Ответ на: комментарий от user_id_68054

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

brotheroftux
()
Ответ на: комментарий от Lincor

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

border-radius
()
Ответ на: комментарий от border-radius

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).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

border-radius
()
Ответ на: комментарий от intelfx

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

border-radius
()
Ответ на: комментарий от border-radius

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

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

intelfx ★★★★★
()
Ответ на: комментарий от border-radius

сделай 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

redgremlin ★★★★★
()
Ответ на: комментарий от intelfx

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

border-radius
()
Ответ на: комментарий от intelfx

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

Lincor
()
Ответ на: комментарий от Lincor
$ 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 уже давно не девственно чистый. Ну и да, я вроде привёл объективный аргумент к тому, почему так всё же стоит делать.

intelfx ★★★★★
()
Ответ на: комментарий от border-radius

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

intelfx ★★★★★
()
Ответ на: комментарий от Lincor

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

der_looser ★★
()
Ответ на: комментарий от der_looser

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

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

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

user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

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

der_looser ★★
()
Ответ на: комментарий от der_looser

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

der_looser ★★
()
Ответ на: комментарий от der_looser

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от der_looser

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

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

redgremlin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.