deepin-default-settings содержит системные настройки, что выглядит странным для настроек DE. Это: %_sysctldir/deepin.conf %_sysconfdir/X11/xinit/xinitrc.d/50-systemd-user.sh %config(noreplace) %_sysconfdir/X11/xorg.conf.d/*.conf %_binfmtdir/wine.conf %config(noreplace) %_sysconfdir/fonts/conf.d/*.conf %_sysconfdir/lscolor-256color %config(noreplace) %_sysconfdir/modprobe.d/*.conf %_sysconfdir/sudoers.d/01_always_set_sudoers_home %_udevrulesdir/99-deepin.rules %_datadir/mime/wine-ini.xml Без всего этого жить нельзя?
(Ответ для Антон Мидюков на комментарий #0) > deepin-default-settings содержит системные настройки, что выглядит странным > для настроек DE. Это: > > %_sysctldir/deepin.conf > %_sysconfdir/X11/xinit/xinitrc.d/50-systemd-user.sh > %config(noreplace) %_sysconfdir/X11/xorg.conf.d/*.conf > %_binfmtdir/wine.conf > %config(noreplace) %_sysconfdir/fonts/conf.d/*.conf > %_sysconfdir/lscolor-256color > %config(noreplace) %_sysconfdir/modprobe.d/*.conf > %_sysconfdir/sudoers.d/01_always_set_sudoers_home > %_udevrulesdir/99-deepin.rules > %_datadir/mime/wine-ini.xml > > Без всего этого жить нельзя? По крайней мере, раньше было нельзя. Периодически DE заводится и без этого пакета. В любом случае, в настоящее время я осторожно пересобираю/обновляю все DDE-пакеты, т.к. при переходе на новую версию среда пока не запускается. В рамках тестов попробую исключить перечисленные файлы и посмотрю, заведётся ли новая версия без них.
(Ответ для Leontiy Volodin на комментарий #1) > (Ответ для Антон Мидюков на комментарий #0) > > deepin-default-settings содержит системные настройки, что выглядит странным > > для настроек DE. Это: > > > > %_sysctldir/deepin.conf > > %_sysconfdir/X11/xinit/xinitrc.d/50-systemd-user.sh > > %config(noreplace) %_sysconfdir/X11/xorg.conf.d/*.conf > > %_binfmtdir/wine.conf > > %config(noreplace) %_sysconfdir/fonts/conf.d/*.conf > > %_sysconfdir/lscolor-256color > > %config(noreplace) %_sysconfdir/modprobe.d/*.conf > > %_sysconfdir/sudoers.d/01_always_set_sudoers_home > > %_udevrulesdir/99-deepin.rules > > %_datadir/mime/wine-ini.xml > > > > Без всего этого жить нельзя? > > По крайней мере, раньше было нельзя. > Периодически DE заводится и без этого пакета. > В любом случае, в настоящее время я осторожно пересобираю/обновляю все > DDE-пакеты, т.к. при переходе на новую версию среда пока не запускается. > В рамках тестов попробую исключить перечисленные файлы и посмотрю, заведётся > ли новая версия без них. Как дела?
(Ответ для AEN на комментарий #2) > (Ответ для Leontiy Volodin на комментарий #1) > > (Ответ для Антон Мидюков на комментарий #0) > > > deepin-default-settings содержит системные настройки, что выглядит странным > > > для настроек DE. Это: > > > > > > %_sysctldir/deepin.conf > > > %_sysconfdir/X11/xinit/xinitrc.d/50-systemd-user.sh > > > %config(noreplace) %_sysconfdir/X11/xorg.conf.d/*.conf > > > %_binfmtdir/wine.conf > > > %config(noreplace) %_sysconfdir/fonts/conf.d/*.conf > > > %_sysconfdir/lscolor-256color > > > %config(noreplace) %_sysconfdir/modprobe.d/*.conf > > > %_sysconfdir/sudoers.d/01_always_set_sudoers_home > > > %_udevrulesdir/99-deepin.rules > > > %_datadir/mime/wine-ini.xml > > > > > > Без всего этого жить нельзя? > > > > По крайней мере, раньше было нельзя. > > Периодически DE заводится и без этого пакета. > > В любом случае, в настоящее время я осторожно пересобираю/обновляю все > > DDE-пакеты, т.к. при переходе на новую версию среда пока не запускается. > > В рамках тестов попробую исключить перечисленные файлы и посмотрю, заведётся > > ли новая версия без них. > > Как дела? После некоторых приготовлений планирую удалить пакет из сизифа - больше в нём нет необходимости.
Ок. Пожалуйста, не откладывайте. И решайте проблему со сборкой qt
Разъясню ситуацию с Qt. Там ровно 2 технических проблемы: 1) Deepin активно использует приватные Qt библиотеки. Это приводит к тому, что при обновлении Qt могут перестать функционировать рабочий стол, док, файловый менеджер и т.д. Чтобы этого не происходило, необходимо пересобирать зависимые пакеты при каждом обновлении Qt, для чего в них сейчас и проставлена зависимость на libqt5-core = %_qt5_version. В свою очередь, это замедляет обновление Qt. Пример: задание 344719. 2) Upstream deepin-а медленно реагирует на появление новых версий Qt. Часто это приводит к тому, что обновление Qt блокируется unmet-ами deepin-а. И если у archlinux не окажется патчей (они единственные, кто продолжает поддерживать новые версии DDE наравне с последними версиями Qt, притом не всегда успешно), то чинить приходится уже самостоятельно. Т.е. deepin иногда блокирует обновление Qt и plasma. Именно этот факт и нервирует zerg-а и rider-а. И не только их. Исхожу из того, что upstream разрабатывает DE, в первую очередь, для своего дистрибутива, где может себе позволить обновлять Qt только по мере готовности deepin-а к этому. В том числе поэтому zerg упомянул про отдельный репозиторий пакетов. Решение здесь только одно - опакетить и сопровождать специальную версию Qt, которая не будет зависеть от системного, и на ней уже собирать deepin. Этим и занят.
По баге: запущено задание 344958 на удаление пакета.
(Ответ для Leontiy Volodin на комментарий #5) > Разъясню ситуацию с Qt. > Там ровно 2 технических проблемы: > > 1) Deepin активно использует приватные Qt библиотеки. > Это приводит к тому, что при обновлении Qt могут перестать функционировать > рабочий стол, док, файловый менеджер и т.д. > Чтобы этого не происходило, необходимо пересобирать зависимые пакеты при > каждом обновлении Qt, для чего в них сейчас и проставлена зависимость на > libqt5-core = %_qt5_version. > В свою очередь, это замедляет обновление Qt. > Пример: задание 344719. > > 2) Upstream deepin-а медленно реагирует на появление новых версий Qt. > Часто это приводит к тому, что обновление Qt блокируется unmet-ами deepin-а. > И если у archlinux не окажется патчей (они единственные, кто продолжает > поддерживать новые версии DDE наравне с последними версиями Qt, притом не > всегда успешно), то чинить приходится уже самостоятельно. > Т.е. deepin иногда блокирует обновление Qt и plasma. > Именно этот факт и нервирует zerg-а и rider-а. И не только их. > Исхожу из того, что upstream разрабатывает DE, в первую очередь, для своего > дистрибутива, где может себе позволить обновлять Qt только по мере > готовности deepin-а к этому. > В том числе поэтому zerg упомянул про отдельный репозиторий пакетов. > > Решение здесь только одно - опакетить и сопровождать специальную версию Qt, > которая не будет зависеть от системного, и на ней уже собирать deepin. Этим > и занят. Да, это выход, наверное Посмотрите еще, как решают эту проблему в Fedora. Замечу, что они основывают свою сборку на на китайском апстриме, а на сборке arch.
Две одновременных Major версии QT в одном репозитории могут приводить к непредсказуемым последствиям. Упакечивать их нужно очень аккуратно.
Пакет удалён.
(Ответ для Anton Farygin на комментарий #8) > Две одновременных Major версии QT в одном репозитории могут приводить к > непредсказуемым последствиям. Упакечивать их нужно очень аккуратно. Пока что это приводит только к превышению лимита на запись со стороны hasher-а: hasher-privd: parent: work_limits_ok: bytes written limit (65536 bytes) exceeded hsh-install: failed to fetch file dependencies from packages being installed. Что интересно, данная ругань замечена только на deepin-kwin2 и deepin-session, а не на всех пакетах, опирающихся на альтернативный Qt.
(Ответ для Leontiy Volodin на комментарий #10) > (Ответ для Anton Farygin на комментарий #8) > > Две одновременных Major версии QT в одном репозитории могут приводить к > > непредсказуемым последствиям. Упакечивать их нужно очень аккуратно. > > Пока что это приводит только к превышению лимита на запись со стороны > hasher-а: > > hasher-privd: parent: work_limits_ok: bytes written limit (65536 bytes) > exceeded > hsh-install: failed to fetch file dependencies from packages being installed. > > Что интересно, данная ругань замечена только на deepin-kwin2 и > deepin-session, а не на всех пакетах, опирающихся на альтернативный Qt. Пока проблема решена отключением AutoReq на проблемных пакетах и проставлением их как BuildRequires на зависимых.
