LINUX.ORG.RU

Моя Gentoo хочет systemd

 , ,


0

2
 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-apps/systemd-200 required by (sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge)
    >=sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge)

  (sys-fs/udev-212-r1::gentoo, installed) pulled in by
    >=sys-fs/udev-208 required by (virtual/udev-208-r2::gentoo, ebuild scheduled for merge)
    >=sys-fs/udev-208:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs?] (>=sys-fs/udev-208:0/0[abi_x86_64(-)]) required by (virtual/libudev-208::gentoo, ebuild scheduled for merge)
    >=sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs?] (>=sys-fs/udev-208-r1:0/0[abi_x86_64(-),gudev,introspection]) required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge)


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

systemd требуется для нового upower, от которого зависят кеды. Вопрос: что курили разработчики?

Вопрос: что курили разработчики?

Уточнение к вопросу: разработчики конкретно чего?

init_6 ★★★★★ ()

upower поставь из тестовой ветки

iVS ★★★★★ ()

eselect profile list

Там будет профиль KDE без systemd

afterlanding ★★ ()

То же самое, зачем-то захотелось ему поставить. Проблема, видимо, в udev. Кстати, интересно стало - пакет безальтернативен или его есть чем заменить?

Bfgeshka ★★★★★ ()

Ставь upower-pm-utils. upower-0.99 требует systemd.

cchr ()

Проблема в том, что в ебилде upower убрали флаг systemd, и теперь systemd требуется всегда.

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

У меня не требует. И вообще такой проблемы не наблюдаю. 0.99.0, правда

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

Правильно сделали. pm-utils — костыль.

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

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

Спасибо! Теперь это г. больше не лезет в мою Gentoo. Но надолго ли?

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

Потому что только в этой системе инициализации сподобились написать некостыльное решение. Как известно, на безрыбье любое земноводное становится рыбой (хотя я считаю, что systemd — вполне себе рыба, т. е. сделан достаточно качественно).

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

На openrc не смотрел, поэтому точно не скажу. А чем хуже?

/* troll mode: лучше тем, что за systemd в техническом комитете Debian отдали четыре голоса, а за openrc — ноль. */

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

Тем, что openrc умеет всё, что мне нужно. Зависимости, параллельный запуск, единообразная настройка сервисов без необходимости редактировать инитскрипты. То есть, есть каталог /etc/conf.d, где лежат конфиги сервисов. Можно поменять зависимости без необходимости править инитскрипт. При перезапуске сервиса перезапускаются все сервисы, зависящие от него. Куча разных настроек. И он просто работает. И при этом не пытается собой заменить полсистемы.

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

«openrc умеет всё, что мне нужно» — не аргумент к тому, что openrc хуже systemd. Тем более что всё описанное есть и в systemd.

Кстати, а где это systemd пытается заменить полсистемы? Или несчастный networkd сам прописывается в список запускаемых сервисов, а по ночам crontab автоматически конвертируется в timer-юниты?

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

Чем systemd лучше openrc?

Тем, что в systemd интегрирован udev, ConsoleKit, PolicyKit, syslog и многое другое… причем почти все элементарно отключается USE флагами ежели оно тебе нэнада.

А самое главное в systemd все это запускается таки параллельно в отличие от

https://en.wikipedia.org/wiki/OpenRC

- Parallel service startup (optional, in development)[3]

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

А чем хуже?

Тем, что не вносит ничего полезного (по крайней мере для десктопа), но вносит много неудобств.

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

Тем, что в systemd интегрирован udev, ConsoleKit, PolicyKit, syslog и многое другое… причем почти все элементарно отключается USE флагами ежели оно тебе нэнада.

Я спрашивал, не чем systemd хуже, а чем он лучше.

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

новое решение работает только на одной единственной системе инициализации

В дебиане при обсуждении тоже некоторые ныли, что части системд от системы инициализации не отцепить. И что, месяца не прошло, как всё от системы инициализации отвязали и теперь non-init-systemd-stuff спокойно работает при любой из четырёх систем инициализации (sysvinit, upstart, systemd, openrc).

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

Тем, что openrc умеет всё, что мне нужно.

Ок. А теперь иди и убеди всех остальных разработчиков кедов, гнома и т.д. в том что openrc им гораздо нужнее и вкуснее чем вражеский systemd. До тех пор разговаривать с тобой не о чем.

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

Логин? Занимается отслеживанием событий с девайсов? Что это за наркомания?

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

Тем, что в systemd интегрирован udev, ConsoleKit, PolicyKit, syslog и многое другое

Иными словами все то же. Да, и я правильно понял, что теперь я не могу обновить отдельно ConsoleKit, мне придется весь комбайн обновлять?

А самое главное в systemd все это запускается таки параллельно в отличие от

Это да. Но что-то только это не вызывает эйфории. Иными словами недостатки пока перевешивают.

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

Полезное я прямо сейчас тебе назову: у меня smbd, sshd и cupsd запускаются автоматически и по необходимости, а не висят в памяти постоянно. И никаких xinetd не нужно. А ещё очень удобно смотреть логи за указанный период от указанного бинарника. А ещё logrotate настраивать не нужно, достаточно написать в конфиге, что под логи отведён один гигабайт места. Как раз в десктопе, где не нужна убер-гибкость cron, syslog, xinetd и так далее, это всё очень приятно.

А в чём неудобства, кроме того, что (о ужас) надо один раз читнуть манцов?

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

Я спрашивал, не чем systemd хуже, а чем он лучше.

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

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

А где здесь, собственно, «заменить»? Перечислены факты интеграции.

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

Иными словами все то же. Да, и я правильно понял, что теперь я не могу обновить отдельно ConsoleKit, мне придется весь комбайн обновлять?

if [[ "весь комбайн" eq systemd ]]; then
echo "Да"
else
echo "Нет"
fi

Это да. Но что-то только это не вызывает эйфории. Иными словами недостатки пока перевешивают.

Это твои личные проблемы а на поверку любая из них {openrc/systemd/upstart} (и да в gentoo есть и upstart ! при желании…) работает без проблем а баги как раз вылазят именно из-за того что отдельные пациенты упороты четко на идее „openrc и больше ничего кроме него“

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

новое решение работает только на одной единственной системе инициализации

а что теперь будет с ubuntu? Там же еще не systemd?

stevejobs ★★★☆☆ ()

я просто поставил laptop-mode-tools и глобально выключил флаг upower. Кедам он больше не потребовался. (Надеюсь я не отстрелил себе ногу?)

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

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

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

Если ты про использование systemd API, то это даже хорошо, т. к. API у них вполне приятные (можно реимплементить). Единственное — хотелось бы, чтобы не было ситуации с 14 стандартами (см. xkcd).

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

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

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

Текущая реализация зависит от systemd, т. к. там есть, чему зависеть. Как известно, функционал из ниоткуда не берётся...

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

У меня upower-0.99, и никакого systemd нет. Может, потому что у меня стоит eudev вместо куска systemd?

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

Это твои личные проблемы

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

и да в gentoo есть и upstart ! при желании

Спасибо, КО.

отдельные пациенты упороты четко на идее „systemd и больше ничего кроме него“

fixed
Нормальные люди взвешиваю все «за» и «против» и принимают для себя решения. А не жрут что дают, а потом на вопрос «а почему так?» начинают лихорадочно гуглить «а правда, а чем лучше?» или оправдываться глупыми отмазками.

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

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

Почему-то consolekit, обладающий почти такой же (хотя и меньшей) функциональностью, ни от чего такого не зависит.

Я, собственно, пару месяцев назад спросил об этом самого Леннарта. Писал, правда, про journald, но это не так важно. Ответ пришел примерно такой: мы не будем обеспечивать поддержку выпила journald, потому что он является монолитной частью systemd, и что бы это сделать, пришлось бы переписывать половину кода. Напомню, что journald - система ведения логов. Отличный показатель качества кода! Не сомневаюсь, что и с logind у них похожая ситуация.

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

Потому что «меньшей». Управление питанием в logind должно взаимодействовать с сессиями пользователей, а те — с механизмом cgroups.

journald как раз имеет полное право быть неотключаемым. Это не система ведения логов, это система сбора логов. Так или иначе, частью функционала systemd является сбор сообщений от всех запущенных демонов. Я думаю, если бы этот функционал был реализован прямо в PID1, это не понравилось бы людям ещё сильнее, и правильно (потому что повышается риск падения PID 1). Следовательно, этот код вынесен в отдельный процесс, но логически функционал по сбору логов всё равно является частью systemd.

А что с логами делать — сохранять своими средствами, отдавать syslog'у или вообще игнорировать — вполне себе настраивается.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от equeim
[I] sys-fs/udev
     Available versions:  208-r1^t 212-r1^t (~)213^t **9999^t {acl doc +firmware-loader gudev introspection +kmod selinux static-libs ABI_MIPS="n32 n64 o32" ABI_X86="32 64 x32"}
     Installed versions:  213^t(12:02:24 AM 05/31/2014)(acl firmware-loader gudev kmod -doc -introspection -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_X86="32 64 -x32")
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

раньше тоже всё ок было. кроме sys-fs/udev-210, там всё сломали. и если забыть про неработоспособность с /usr на отдельном разделе(кому это может понадобиться?).

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

В systemd хороший код и совершенно приемлемая команда разработчиков. Дело в том, что некоторые вещи гораздо проще сделать неотключаемыми, но всё равно PID 1 там достаточно маленький.

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

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

Яйца, одна корзина, все дела.

Когда у тебя протухло одно яйцо (sysvinit ->openrc), ты можешь его выкинуть и заменить на другое. Когда у тебя протухла курица (леннарт), несущая яйца, интегрированные друг в друга, становится сложней.

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

Нужно не API, а метод интеллектуального анализа конфигурации системы, чтобы софт мог адаптироваться под разные системы. Для этого со стороны системы нужно API на интроспекцию, а для со стороны софта - анализаторы. Но нет, быдлокодеры нафигачат апи и прибьют к нему все гвоздями. А когда систему нужно будет запустить на квадракоптере, все рухнет нафиг с out of memory. В качестве лечения предлагаю пожизненный эцих с гвоздями.

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

Плохо что теперь производители софта и железа будут ориентироваться на systemd.

Плохо для кого?

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