(Ответ для Антон Мидюков на комментарий #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 на зависимых.