Упустили из новостей сайта эту новость. В соцсетях же везде было написано отдельной темой. Например https://vk.com/calculatelinux#/calculatelinux?w=wall-10221243_8401 Тут же описаны и причины. Условие поправим.

Не все в соц сетях проводят массу времени :) Мне гораздо удобнее читать RSS ленту.
Условие лучше сделать на основе USE флага. Только вот как быть с теми пакетами, которые не несут в себе USE флаг systemd, но имеют какой либо юнит для него в своем составе. Допустим, что пакет установлен до смены системы инициализации, и все "левые" файлы в нем уже порезаны, выходит он не переустановится при emerge -uDN world после объявления USE="systemd" Я правильно рассуждаю?

Условие лучше сделать на основе USE флага. Только вот как быть с теми пакетами, которые не несут в себе USE флаг systemd, но имеют какой либо юнит для него в своем составе. Допустим, что пакет установлен до смены системы инициализации, и все "левые" файлы в нем уже порезаны, выходит он не переустановится при emerge -uDN world после объявления USE="systemd" Я правильно рассуждаю?

Всё верно. Тем не менее, в бинарных пакетах эти настройки остаются нетронутыми.

1. Наверное вы имеете в виду, что файлы "от systemd" в бинарных пакетах остаются не тронутыми?
2. ISO образ при подготовке эти файлы тоже не затрагивает?
3. А бинарный пакет при установке попадает под этот хук?

Все-таки я склоняюсь что такое решение очень опасно, хорошо мне повезло, что я не задолго до этого обновления мигрировал на openrc на своей рабочей машине, иначе мог потерять рабочий день на восстановление системы после обновления (openrc в системе присутствовал). А что если таких машин целый парк? Нельзя же вот так, можно сказать задним числом (VK не считается), вводить такие критические изменения по умолчанию. Если и вводить, то полагаясь на выбор пользователя. Например, если он захочет этого, то мог бы указать FEATURES="clean_systemd" в make.conf.

Неясны мне мотивы дистрибутива, ввод оверлеев дает огромные возможности по кастомизации, и вместе с тем палки в колеса для systemd вставляете... :(

Соглашусь с Михаилом Гагаузом, что наличие неких "посторонних" файлов в системе вообще не критично, и что в незнакомой системе для проверки наличия systemd первое что приходит в голову это systemctl, но лично я использую pidof systemd. Берусь утверждать, что Ваша забота о конечном пользователе в конечном итоге сыграла злую шутку над ним же.

Как итог всех моих злоключений, после нескольких часов компиляции в KVM, я имею не до конца работающую систему с systemd. И как теперь её починить не начиная все с самого начала никакого представления. От openrc я избавился через /etc/portage/packages, и переустановил некоторые пострадавшие сервисы вручную, такие как sshd и dbus. Но неизвестно что еще пострадало. Наверное придется писать "онлайнер" для переустановки всех установленных пакетов в системе, а это еще прорва времени...

Сергей Федотов wrote:

1. Наверное вы имеете в виду, что файлы "от systemd" в бинарных пакетах остаются не тронутыми?

Именно, речь же о них, как я понял.

2. ISO образ при подготовке эти файлы тоже не затрагивает?

Пакеты в подготавливаемых образах ставятся таким же образом, как и в живой системе. Соответственно в конечном ISO их нет.

3. А бинарный пакет при установке попадает под этот хук?

Да. В самом же архиве остаётся оригинальное содержание.

Все-таки я склоняюсь что такое решение очень опасно, хорошо мне повезло, что я не задолго до этого обновления мигрировал на openrc на своей рабочей машине, иначе мог потерять рабочий день на восстановление системы после обновления (openrc в системе присутствовал). А что если таких машин целый парк? Нельзя же вот так, можно сказать задним числом (VK не считается), вводить такие критические изменения по умолчанию. Если и вводить, то полагаясь на выбор пользователя. Например, если он захочет этого, то мог бы указать FEATURES="clean_systemd" в make.conf.

Помимо vk, новость была опубликована в группах facebook и google+. Чистка производится только в обновляемых пакетах. С условием проверки согласен, правильней проверять на наличие установленного systemd.

Неясны мне мотивы дистрибутива, ввод оверлеев дает огромные возможности по кастомизации, и вместе с тем палки в колеса для systemd вставляете... :(

Это не палка, а оптимизация. Причины описаны. Пользователи имели возможность высказаться на этот счёт.

Соглашусь с Михаилом Гагаузом, что наличие неких "посторонних" файлов в системе вообще не критично, и что в незнакомой системе для проверки наличия systemd первое что приходит в голову это systemctl, но лично я использую pidof systemd. Берусь утверждать, что Ваша забота о конечном пользователе в конечном итоге сыграла злую шутку над ним же.

Разумеется, мнение Михаила так же учтено. Я с ним общался по телефону по этому поводу.

Как итог всех моих злоключений, после нескольких часов компиляции в KVM, я имею не до конца работающую систему с systemd. И как теперь её починить не начиная все с самого начала никакого представления. От openrc я избавился через /etc/portage/packages, и переустановил некоторые пострадавшие сервисы вручную, такие как sshd и dbus. Но неизвестно что еще пострадало. Наверное придется писать "онлайнер" для переустановки всех установленных пакетов в системе, а это еще прорва времени...

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

Столь радикальная на первый взгляд мера была вызвана неоднозначной ситуацией. Это не удел FEATURES с одной стороны, с другой это не удел USE, т.к. настройки без зависимости к systemd добавляются ко всем пакетам самими разработчиками. На переменную утилит так же нет смысла вешать эту обязанность, т.к. официальной поддержки systemd в кальке нет.

Alexander Tratsevskiy wrote:

2. ISO образ при подготовке эти файлы тоже не затрагивает?

Пакеты в подготавливаемых образах ставятся таким же образом, как и в живой системе. Соответственно в конечном ISO их нет.

Помимо vk, новость была опубликована в группах facebook и google+. Чистка производится только в обновляемых пакетах. С условием проверки согласен, правильней проверять на наличие установленного systemd.

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

На официальном сайте новости нет, а в социалочках есть, нормально!
Т.е. загруженный ISO заведомо почищен от "неугодных" файлов, условие вы поправили на проверку наличия установленного systemd, но при его установке пакеты все так-же будут чистится, в том числе и сам пакет systemd, делая его не работоспособным. Я объявляю USE="systemd" и при ребилде мира, а это около 80 пакетов в CLS, продолжаю ломать систему. Где тут решение проблемы? Без повторной переустановки всего не обойтись... Только если самому не подготавливать ISO нужным образом.

Неясны мне мотивы дистрибутива, ввод оверлеев дает огромные возможности по кастомизации, и вместе с тем палки в колеса для systemd вставляете... :(

Это не палка, а оптимизация. Причины описаны. Пользователи имели возможность высказаться на этот счёт.

"оптимизация" и "причины"

P.S. Не подумайте чего, я ваш пользователь уже года 4, и благодарен за ваш труд, но сегодня впервые усомнился в своем выборе.

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

условие вы поправили на проверку наличия установленного systemd, но при его установке пакеты все так-же будут чистится, в том числе и сам пакет systemd, делая его не работоспособным.

Условие отрабатывает после установки пакета, т.е. systemd к этому времени будет стоять.

Да, о таких "оптимизациях" хорошо бы предупреждать на основном сайте

Нехорошо получилось, согласен. Редко такие глобальные вещи проходят.

Alexander Tratsevskiy wrote:

условие вы поправили на проверку наличия установленного systemd, но при его установке пакеты все так-же будут чистится, в том числе и сам пакет systemd, делая его не работоспособным.

Условие отрабатывает после установки пакета, т.е. systemd к этому времени будет стоять.

Разве? Я почему-то сделал вывод, что оно отрабатывает где-то между стадий install и qmerge.

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

На заметку, сделав тест на отцовство файлов в /usr/lib/systemd/* на рабочей машине, и сравнив их с установленными пакетами на пострадавшей, получил возможный список пострадавших пакетов:

dev-db/mysql-init-scripts
dev-vcs/git
net-firewall/iptables
net-fs/nfs-utils
net-misc/dhcp
net-misc/openssh
net-misc/rsync
net-nds/openldap
net-nds/rpcbind
net-print/cups-filters
net-wireless/wpa_supplicant
sys-auth/polkit
sys-fs/lvm2
sys-fs/mdadm
sys-libs/glibc
sys-libs/gpm

Разве? Я почему-то сделал вывод, что оно отрабатывает где-то между стадий install и qmerge.

pre_pkg_postinst() выполняется, когда пакет уже в системе

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

Настройки обновляются ревизией 86:
/var/lib/layman/calculate/profiles/templates/3.3/6_ac_update_sync/remerge/86

условие все то же. когда выкатит?

Попробуйте выполнить dispatch-conf

проверка в 40-й строке /etc/calculate/profile.bashrc.d/50-setup-package

На заметку, сделав тест на отцовство файлов в /usr/lib/systemd/* на рабочей машине, и сравнив их с установленными пакетами на пострадавшей, получил возможный список пострадавших пакетов

При желании не составит большого труда вытащить настройки из зеркала grp.

Alexander Tratsevskiy wrote:

Настройки обновляются ревизией 86:
/var/lib/layman/calculate/profiles/templates/3.3/6_ac_update_sync/remerge/86

сделал eix-sync, но последняя ревизия 83, в тестовом бранче затерялось?

Сергей Федотов wrote:

Alexander Tratsevskiy wrote:

Настройки обновляются ревизией 86:
/var/lib/layman/calculate/profiles/templates/3.3/6_ac_update_sync/remerge/86

сделал eix-sync, но последняя ревизия 83, в тестовом бранче затерялось?

Почему в тестовом? Вы же можете проверить:
http://git.calculate.ru/?p=calculate/overlay.git;a=tree
Сравнить у себя то что в шаблонах remerge и в /etc/calculate/ini.env
Если у вас старая версия, то значит смотрите в сторону бинарного репозитория.

загрузился с флешки, сделал chroot в основную систему, потом cl-update -s, после этого переустановил все пакеты обновленные в декабре и все заработало.

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

Alexander Pilipenko wrote:

загрузился с флешки, сделал chroot в основную систему, потом cl-update -s, после этого переустановил все пакеты обновленные в декабре и все заработало.

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

26-27 ноября.