Systemd на stage3

Он не «сносит openrc». Пропиши openrc в world, пока гентушные наркоманы осилят его по нормальному выпилить/прописать в зависимости.

Зависит от версии и юз-флагов.
А так emerge -pv systemd и смотришь выхлоп по пакетам, кто что блокирует, где какие петли, что и как по юзам подтягивается. Особой магии нет, всё традиционно, но нужно смотреть что пишут пакеты при установке. Например, какие изменения внести в параметр init передаваемый ядру в загрузчике.

https://bugs.gentoo.org/show_bug.cgi?id=373219

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

в принципе можешь functions.sh и сам выдернуть из openrc временно.

Всё правильно, удаляете sys-fs/udev и ставите sys-apps/systemd. Только удостоверьтесь, что бы флаги, с которым вы собрали sys-apps/systemd удовлетворяли зависимостям виртуального пакета virtual/udev

RDEPEND=«|| ( >=sys-fs/udev-200[gudev?,hwdb?,introspection?,keymap?,kmod?,selinux?,static-libs?]
	>=sys-apps/systemd-200[gudev?,introspection?,keymap(+)?,kmod?,selinux?,static-libs(-)?]
	kmod? ( >=sys-fs/eudev-1[modutils,gudev?,hwdb?,introspection?,keymap?,selinux?,static-libs?] )
	!kmod? ( >=sys-fs/eudev-1[gudev?,hwdb?,introspection?,keymap?,selinux?,static-libs?] )
	)»

После установки sys-apps/systemd проверяйте так:

emerge -pv virtual/udev

Ну и смотрите эту wiki http://wiki.gentoo.org/wiki/Systemd .

[ebuild R ] sys-apps/systemd-206-r1 USE=«acl cryptsetup filecaps firmware-loader gcrypt gudev http introspection kmod lzma openrc pam policykit qrcode tcpd xattr -audit -doc -python (-selinux) {-test} -vanilla» PYTHON_SINGLE_TARGET=«python2_7» PYTHON_TARGETS=«python2_7» 0 kB
[ebuild R ] sys-apps/openrc-0.12_pre1-r1::systemd-love USE=«ncurses pam unicode -debug -newnet (-prefix) (-selinux) -static-libs» 0 kB

Что-то со сносом openrc непонятно, но у меня конечно не чистый стейж, а ужасный суррогат из дженты, фанты и оверлеев.

покамись пересоберу гцц под проц, потом дальше будем мерджить

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

udev-init-scripts оставить??

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

можно как-нибудь захардкодить в ядро, или сделать линк /sbin/init -> куда-то-туда. Если ядро не будет знать, где лежит инит, то как оно узнает, что нужно грузить именно systemd?

Оставьте.

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

пока прописал в строке..

надо настроить загрузку сервисов и разобраться с их управлением а так 7,5с загрузка - 2с на ядро..

и при загрузке ругается(как впрочем и при сброке) на ipv6, которую я убрал

расскажите, как убрать ненужные сервисы из всех «run-level'ов»??

судя по арч-вики, сис-д может заменить acpi+pm-utils(частично, события ацп кое-какие не обрабатывается), это самому собирать сервис с нужными командами??

расскажите, как убрать ненужные сервисы из всех «run-level'ов»??

кажется вы неправильно меня поняли, я начинающий openrc дев и я не умею в systemd :). Я знаю только некоторые интересующие меня аспекты его работы. Ну и баги связанные с openrc я знаю.

по системд в генте тут vasily_pupkin много чего рассказать может.

Ох уж эти девелоперы генты — как батхёртить от обоснованой критики их поделок тут как тут, а как совета/консультации спросить, они нифига не знают и в кусты.

расскажите, как убрать ненужные сервисы из всех «run-level'ов»??

Там нет ранлевелов. В любом случае лучше прочитать man bootup systemd.preset systemctl

сис-д может заменить acpi+pm-utils

Скорее нет чем да, если не накостылять костылей самому

подробнее про батхерты от обоснованной критики, и почему я должен давать советы/консультации по поводу продукта, с которым я абсолютно никак не связан?

я потому и взял в скобки.. что их нет..

не пойму как сократить список загружаемых сервисов??

костыли?? к acpi и pm-utils тож костыли прикручиваются(грубо говоря)

не пойму как сократить список загружаемых сервисов??

Что это значит?

не пойму как сократить список загружаемых сервисов??

Чем вариант с systemctl disable kdm.service не подошёл?

systemctl disable systemd*-сервис(не помню какой именно) не хочет блокировать нужный мне сервис.

пока ничего не добавлял.. кстати, файлы конфигурации так же читаются(настройки консоли, окружения и т.д.)??

как правильно поставить системд??

USE=«systemd» в make.conf и обновить систему?

как понимаю, при «установке» он удаляет удев и нет пакетов просящих опенрс ?..

sys-apps/systemd при установке удаляет sys-fs/udev так как во первых systemd и так включает в себя udev а во вторых к примеру в том же sys-apps/systemd-208-r3 есть:

RDEPEND="${COMMON_DEPEND}
	>=sys-apps/baselayout-2.2
	|| (
		>=sys-apps/util-linux-2.22
		<sys-apps/sysvinit-2.88-r4
	)
	!sys-auth/nss-myhostname
	!<sys-libs/glibc-2.10
	!sys-fs/udev"

Догадайся с трех раз что значит !sys-fs/udev

PS: первая попытка была неудачной.. после установки системд снес удев и опенрс.. и гцц отказался собираться.. плюс гцц-конфиг не может найти файл от опенрс..

А вот за это скажи спасибо тем идиотам из майнтрейнеров гента которые не прописали зависимости от openrc там где они были необходимы.

https://bugs.gentoo.org/show_bug.cgi?id=373219

qnikst а теперь пожалуйста поподробнее каким боком тот баг касается того факта что в том же sys-devel/gcc потроха которого (да да тот самый gcc-config) юзают тот самый /etc/init.d/functions.sh который в данный момент предоставляет исключительно только один единственный sys-apps/openrc

$ grep functions.sh /var/gentoo/portage/sys-devel/gcc-config/files/gcc-config-1.5.1
source /etc/init.d/functions.sh || {
	echo "${argv0}: Could not source /etc/init.d/functions.sh!" 1>&2
			# nothing to do; functions.sh parsed this for us

В sys-devel/gcc-config так же как и во многих других поломанных пакетах тупо не прописаны зависимости от того что именно они используют!!!

все вопросы по gcc-config к Вапиру.

все вопросы по gcc-config к Вапиру.

Во этот вопрос касается не исключительно одного единственного sys-devel/gcc-config. А как же: app-admin/perl-cleaner, app-admin/python-updater, app-portage/gentoolkit,sys-devel/binutils-config… и возможно многих и многих других поломанных подобным же образом пакетов которые таким же образом как и sys-devel/gcc-config используют /etc/init.d/functions.sh хотя никаких зависимостей от sys-apps/openrc в них не прописано.

И вопрос отсутствующих либо непрописанных зависимостей никак не касается https://bugs.gentoo.org/show_bug.cgi?id=373219 альтернативной реализации /etc/init.d/functions.sh из sys-apps/openrc.

с сказал к Вапиру, значит к Вапиру, отдуваться за него я не собираюсь, ситуация известна, и это (во всяком случае решение ситуации) относится к тому багу.

А вот это

27 Aug 2013; Ulrich Müller <ulm@gentoo.org> packages: Temporarily add sys-apps/openrc to the system set, until bug 373219 is resolved.

вообще замечательно. "Зависимости у нас пролюблены и не прописаны но до тех пор пока не закрыт баг где плодят альтернативу functions.sh и который в данном случае не имеет никакого отношения к непрописанным и пролюбленным зависимостям мы тупо вхерачим openrc в @system и нам норм."

Где достать такие-же грибы и в таких-же количествах?

ты читать умеешь? повторю третий раз, я сказал «К ВА-ПИ-РУ!», я не знаю чем он думает и почему он так сделал, он в курсе этой проблемы, можешь заодно и про грибы спросить.

с сказал к Вапиру, значит к Вапиру, отдуваться за него я не собираюсь, ситуация известна, и это (во всяком случае решение ситуации) относится к тому багу.

А я сказал баг ТС с gcc-config не имеет никакого отношения к https://bugs.gentoo.org/show_bug.cgi?id=373219

ты уже поговорил с вапиром?

ты уже поговорил с вапиром?

А ты на вапирав стрелы не переводи.

Если что то все это говно с непрописанными зависимостями исправляется за пару минут при желании.

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

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

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

А ну если именно так и никак поступать велит дерьмо-policy или дерьмо-QA то это безусловно все оправдывает.

И еще раз мне не нужно никого спрашивать для того чтобы увидеть и даже самому убедится в том что зависимости таки пролюблены. После этого понять каким образом зависимости пролюбили еще проще(особенно если еще и вспомнить весь цирк с eudev/udev/systemd в gentoo) а тот баг #373219 не имеет никакого отношения к изначальной проблеме пролюбленых зависимостей.

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

Если девелоперы в самой генте зная обо всем этом дерьме тем не менее ничего не делают для исправления этого «не бага» то куда уж мне тупому и убогому до их великолепной гениальности?

чо ты ко мне-то пристал? Нету - зависимостей - нету; почему нету - потому, что functions.sh и openrc были в @system + какие-то соображения вапира, о которых ты можешь узнать у него; почему - не добавят - проси у вапира, почему не добавлю я - у меня нету на это прав. Едиственный способ решить эту проблему в текущих условиях - выделить в отдельный пакет (#373219) и добавить зависимость на него. Точка. Все.

чо ты ко мне-то пристал?

А чо ты на #373219 сослался?

Едиственный способ решить эту проблему в текущих условиях - выделить в отдельный пакет (#373219) и добавить зависимость на него. Точка. Все.

Нет не единственный. Мало того этот твой «едиственный способ» вообще не то как нужно исправлять конкретно это дерьмо.

Надо virtual/functions который будет таскать либо openrc либо на ту херь которую родят после того как закроют #373219. Аналогично тем же virtual/linux-sources и многим другим подобным им… И зависимости должны быть от этого virtual/functions а не сразу от openrc или от того что родят после того как закроют #373219.

И можешь спросить любого первого попавшегося гентушника который хоть немного вкурил что да как в портежах и он ответит тебе так же!

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

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

На эти «кажущиеся очевидными вещи» девелопиры гент по каким-то неведомым причинам положили огромный болт и в результате все скатывается к разброду и шатаниям вроде Желающие принять участие в написании альтернативы portage на C++ просьба отписаться которые тоже возникают не на пустом месте а вот от подобных «очевидных вещей».

Я тебе сказал, как узнать причину, почему ты упорно это игнорируешь? Понимаешь в этом баге всем настрать на то, что думаешь ты или я или абстрактный дев или гентушник, есть «неведомые» причины о которых человек, у которого они были отписывался, но я не уверен, что я осилил их логичность и искать не буду. Пока причины, по которым добавить зависимость на openrc по мнению вапиера нельзя, не будут исправлены - проблема будет оставаться, а причины какие-то есть. Есть единственная реальная возможность исправления данной ситуации - это решение #373219, поэтому я и привел ссылку на этот баг.

Я тебе сказал, как узнать причину, почему ты упорно это игнорируешь?

Любые оправдания и мнения несущественны а истина заключается в том, что если некий обобщенный ebuild А ставит нечто что в свою очередь использует /etc/init.d/functions.sh который в данном случае покамест еще не закрыт баг #373219 принадлежит исключительно только openrc следовательно этот ebuild А просто обязан иметь зависимость от openrc.

А что должно быть когда закроют баг #373219 уже написано выше.

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

«Неведомые» причины несущественны.

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

Конечно нельзя. Иначе сразу невооруженным взглядом любому станет видно все то дерьмо коим на самом деле и являются в данное время все те «зависимости» в ebuild-ах.

Есть единственная реальная возможность исправления данной ситуации - это решение #373219, поэтому я и привел ссылку на этот баг.

И еще раз заостряю внимание на том, что тот баг #373219 касается создания альтернативы /etc/init.d/functions.sh которое в данный момент предоставляет исключительно одно openrc… И то что баг #373219 открыт это круто и все такое… но оно никак не касается того что зависимости от openrc намерено ПРОСРАНЫ и в данный момент попросту не существует на тех местах где они обязаны быть. А следовательно даже созданная альтернатива /etc/init.d/functions.sh т.е. закрытый баг #373219 никак сука и ничем не гарантирует того, что ПРОСРАННЫЕ зависимости от openrc ВНЕЗАПНО откуда-то по мановению чей-то волшебной палочки явятся.

я не понимаю чего ты тут время тратишь? Я знаю, что там нету зависимостей на openrc, и я знаю, что base-system не собираются их добавлять, а у всех кроме base-system нету на это прав. И сказал, что ЕДИНСТВЕННЫЙ способ исправить ситуацию это пофиксить #373219 зависимость на новый пакет base-system готовы добавить. Писать все эти простыни мне не имеет никакого смысла.

Писать все эти простыни мне не имеет никакого смысла.

Так же как и тыкать всякими https://bugs.gentoo.org/show_bug.cgi?id=373219 аналогично не имеет никакого смысла.

молодцы, гентушники. Уже начинаете пробовать разные позы.

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

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

Да. Тыкать на баг имеющий посредственное отношение к проблеме намерено просранных зависимостей в данном случае не имеет никакого смысла. И да зачем «поправлять ситуацию» если можно было просто изначально не разводить срача в зависимостях? Но это видимо слишком просто а употребленные грибы подсказали более изумительный путь…