Reenable systemd units that create symlinks via the 'Alias' option #5549
Conversation
Bug: https://bugs.gentoo.org/627984 Package-Manager: Portage-2.3.6_p39, Repoman-2.3.3_p17
Bug: https://bugs.gentoo.org/628454 Package-Manager: Portage-2.3.6_p39, Repoman-2.3.3_p17
|
cc @gentoo/kde @gentoo/gnome @gentoo/lxqt @gentoo/systemd |
Package-Manager: Portage-2.3.6_p39, Repoman-2.3.3_p17
|
it sounds to me as it should apply to a lot more than this. Shouldn't apply to any package providing units ? What about user units ? |
Most units are unaffected by the rootprefix change; systemd ignores symlink targets within .wants/ directories.
Impossible to fix from the package manager. |
|
+1 for merge but I think some kind of announcement must be done to fellow devs so we do not miss this new systemd eclass call when needed. Maybe a QA check in portage like the recently added icon cache update detection. |
Actually, user-units are unaffected by the rootprefix change: they still get installed in |
|
I think it'd be nice to actually explain there when it needs to be used and when not. |
|
I added a paragraph explaining intended use of the |
floppym
force-pushed
the
systemd-reenable
branch
from
cc4bc4a
to
1aa2265
Compare
floppym
changed the title
|
😞 The QA check for this pull request has found the following issues: Issues inherited from Gentoo (may be modified by PR): |
|
Rebased and merged. |
This is needed to keep things working when some packages are rebuilt after upgrading to systemd 234.