(gentoo) Ни у кого нет проблем, с тем, что virtual/udev теперь указывает на sys-fs/eudev, а не на udev?

[ebuild U ] sys-fs/udev-197-r4 [197-r3] USE=«acl gudev hwdb introspection keymap kmod openrc -doc (-selinux) -static-libs» 0 kB

Нормально все ставится и апгрейдится, в общем-то.

У тебя оверлеев случайно нету никаких левых?
У меня на ~amd64 система, есличо.

сижу на:

sys-fs/udev-196-r1
virtual/udev-196
sys-fs/udev-init-scripts-19

[ebuild     U  ] sys-fs/udev-197-r4 [196-r1] USE="acl gudev hwdb keymap kmod openrc -doc -introspection (-selinux) -static-libs" 2,008 kB
[ebuild     U  ] virtual/udev-197 [196] USE="gudev hwdb keymap -introspection (-selinux) -static-libs" 0 kB

Total: 2 packages (2 upgrades), Size of downloads: 2,008 kB

Есть, но на eudev, udev, и virtual/udev ничего нет.
=virtual/udev-197 на что ссылается? emerge --sync сделал?

emerge --sync сделал?

Ага, сразу перед тем как обновится.

 * Messages for package sys-fs/udev-197-r4:

 * 
 * Please re-emerge all packages on your system which install
 * rules and helpers in /usr/lib/udev. They should now be in
 * /lib/udev.
 * 
 * One way to do this is to run the following command:
 * emerge -av1 $(qfile -q -S -C /usr/lib/udev)
 * Note that qfile can be found in app-portage/portage-utils
 * 
 * You need to restart udev as soon as possible to make the upgrade go
 * into effect.
 * The method you use to do this depends on your init system.
 * 
 * Old versions of installed libraries were detected on your system.
 * In order to avoid breaking packages that depend on these old libs,
 * the libraries are not being removed.  You need to run revdep-rebuild
 * in order to remove these old dependencies.  If you do not have this
 * helper program, simply emerge the 'gentoolkit' package.
 * 
 *   # revdep-rebuild --library '/lib64/libudev.so.0' && rm '/lib64/libudev.so.0'
 * 
 * For more information on udev on Gentoo, writing udev rules, and
 *          fixing known issues visit:
 *          http://www.gentoo.org/doc/en/udev-guide.xml
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

Как видишь стянул удев и ничего не сказал после обновления.

virtual/udev сделан для установки или udev или eudev, посмотрите его содердимое.

Дык это. eudev уже не совместим с udev-197. Так что или маскай virtual/udev-197, или размаскируй eudev beta, или что там

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

В файл /etc/portage/profile/package.provided добавь строку с sys-fs/eudev-0 и живи спокойно и счастливо хоть с eudev, хоть с udev.

Хм, обратил внимание на флаги.
Должно быть минимум так:
virtual/udev gudev hwdb
sys-fs/udev gudev hwdb

Теперь всё ок.

Только мне это совершенно не очевидно из ебилда /usr/portage/virtual/udev/udev-197.ebuild . Там же две одинаковые строчки, значит он должен выбрать тот вариант, который не вызывает конфликтов, разве не так?

Там же две одинаковые строчки, значит он должен выбрать тот вариант, который не вызывает конфликтов, разве не так?

Вот это уже не ко мне, я не в курсе логики портажа.

В файл /etc/portage/profile/package.provided добавь строку с sys-fs/eudev-0 и живи спокойно и счастливо хоть с eudev, хоть с udev.

Нет, так делать крайне костыльно, и в данном случае бессмысленно. Тут вопрос о зависимостях, а не о проблемах компиляции. А если ты про то, что можно ставить потом другой пакет вручную через ebuild, то очень тоже несколько не тру, особенно при обновлении мира или при линковки с его кусками других приложений. В общем, так лучше не делать.

virtual/udev сделан для установки или udev или eudev, посмотрите его содердимое.

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

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

Причём тут поттерингохейтеры? udev сейчас безальтернативен, а его форк (тоже самое, только без systemd) ещё нормально не интегрирован в экосистему. Это не пульс и не systemd.

Разбил себе всё лицо фейспалмами. Это тебе поп в церкви напел про костыли? Я тебе предложил самый простой и правильный путь решения твоей проблемы, которую те четыре гиперкостыля, которые ты в посте понапридумал, не решают.

В общем, так лучше не делать.

Ага, поучи меня блокировки разруливать. :D

Где же они одинаковые, или вы ослепли ? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/virtual/udev/udev-197...

...
RDEPEND="|| ( >=sys-fs/udev-197-r3[gudev?,hwdb?,introspection?,keymap?,selinux?,static-libs?]
 	>=sys-fs/eudev-1_beta1[gudev?,hwdb?,introspection?,keymap?,selinux?,static-libs?] )"

В первом случае udev-197-r3 далее стоит условие «или» (||) а затем eudev-1_beta1

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

То, что Вы предлагаете гарантированно ведет к жопе при дальнейшей эксплуатации, и, тем более, при переносе на другие системы. Мало того, package.provided предоставляет свои функции только для определенной версии пакета, а не для всех версий данного пакета. В результате нужно либо постоянно следить за версиями, либо писать костыль к портажу, либо маскировать все версии выше данной. Последнее может привести к невозможности (причём портаж об этом не скажет, а просто будет юзать старые версии, пока их не удалят из дерева) апдейта кучи пакетов, у которых данный в зависимостях. Даже на офф сайте про package.provided сказано, что это - грязный хак, который нужен больше для мейнтейнеров для быстрых проверок своих догадок неработоспособности. В случае же установкой левого ПО, нужен либо ебилд, либо в /opt.
Если мне не изменяет память, то при прямой установке через ebuild также по пакету правильную инфу equery не будет выводить.

Ага, поучи меня блокировки разруливать. :D

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

Нисколько не ослеп. Вы просто не поняли, что под «одинаковые» я подразумевал логику флагов. То, что они не могут быть по-символьно одинаковы и так ясно.

нет никаких проблем на eudev
просто udev оставь для леннародоса и зондированных

просто udev оставь для леннародоса и зондированных

171 ещё в дереве, алё.

если ничего не установлено - выбрать первый из списка.

по поводу зависимостей от sys-fs/udev в главном дереве(про оверлеи - хз) - некоторые пакеты таки нужно тестить с eudev. Например dracut - соответствующий баг можешь почитать на bugs.gentoo.org

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

сейчас стабилится хренова гора пакетов которые будут требовать >=virtual/udev-197, так что либо он, либо eudev

А мне он, как раз, весьма нужен.

Как всё будет без проблем с ним работать (особенно dracut), так сразу. На данный момент большой разницы не вижу, т.к. у меня не фря (касаемо kmod), а systemd там ещё обязательно не нужен пока. В общем, на данный момент мне рановато на eudev переходить, я считаю.

А там (в >171-r9/10) вообще есть что полезное? А то я и так люблю посидеть на камешках, а тут ещё гору пакетов стабилизируют, как ты говоришь.

Ох уж намаялся я с этим 197-м уудевом, не обратив внимания на сообщение после мержа!

Безусловно!

Это хорошо.

Глупо вопрос построил, да. Имелось ввиду насколько сейчас разобрались с eudev, и безопасно ли на него вообще переходить? А то дело-то рисковое. И почему я не получал никаких сообщений и предложений о переходе на eudev? Или к тому времени, как я занялся обновлением, переход на eudev автоматом уже выпилили и оставили вместо него старый udev?

171 ещё в дереве, алё.

Вчера на рабочей машинке прокатил маск sys-fs/udev и virtual/udev выше версии 171 в package.mask. А сегодня на домашней уже не катит. Похоже, процесс пошел и уже фиг остановишь. Гореть Поцтерингу в аду стопицоттыщмиллионов лет.:)

прокатил маск sys-fs/udev и virtual/udev выше версии 171 в package.mask. А сегодня на домашней уже не катит.

Так те, что в дереве, они выше 171, там в стейбле 171-r9 и ещё 171-r10 в анстейбле.

Из замеченного мной полезного - работа с общей базой идентификаторов оборудования(hwids). Может еще что - не замечал. Главное - регрессий нет, тьфу-тьфу

Переход не обязательный - те у кого был sys-fs/udev просто продолжать обновляться дальше. Но есть возможность заменить его на eudev

Из кусков systemd там - только одно название.
Если даже и от него тошнит - переходи на eudev

Так и сделал.:) Кстати, как выяснилось, виноват был udisks - это он новую версию udev'а хотел. Пока замаскировал его, а там видно будет.

ЗЫж Блин, только на праздниках систему пересобрал... эх, знать бы про такую засаду...

А что за засада то с новым udev, про которую уже пара человек говорит?

конкретизируй, не распарсил

ЗЫж Блин, только на праздниках систему пересобрал... эх, знать бы про такую засаду...
Ох уж намаялся я с этим 197-м уудевом, не обратив внимания на сообщение после мержа!

а, это. Ну так emerge @preserved-rebuild в помощь :)

прочитай вылоп: (gentoo) Ни у кого нет проблем, с тем, что virtual/udev теперь указывает на sys-fs/eudev, а не на udev? (комментарий)

Please re-emerge all packages on your system which install rules and helpers in /usr/lib/udev. They should now be in /lib/udev.

Не поможет, там не путь к либе сменился, а путь к udev-rules файлам.

ну хз, у меня 2 десктопа и пара серверов уже пережили апгрейд

Беру свои слова обратно - 1 сервер апгрейд безболезненно не пережил. И походу я обнаружил парочку новых багов >_<

Апгрейд по новый удев или на eudev? Какие баги?

Как минимум - persistent-net-rules могут не взлететь: https://bugs.gentoo.org/show_bug.cgi?id=453494

нафига ты ставишь эти свои круглые скобочки?

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

для этого тэги есть

Я в них и писал. Они тогда и лезли. Теперь лезть перестали.

У меня в итоге все нормально, пришлось пересобрать два+ десятка пакетов, глюков не заметил. Единственно беспокоит - как переживет оффлайн-обновление ноутбук на даче. Там NM, опасаюсь, как бы с ним траблов не было.