Hi Jaroslav,
El dl 13 de 05 de 2013 a les 09:12 +0200, en/na Jaroslav Kysela va escriure:
http://patch-tracker.debian.org/patch/series/view/alsa-utils/1.0.27-2/alsa-r...
This one I want to discuss. We think the After condition is wrong, as it's depending on an optional service (alsa-state might not happen if the config file is not present). Instead, it should be checking for sysinit, to ensure local-fs.
The condition is not wrong and it is expected that both services alsa-state/alsa-restore will be in the system, even if one is disabled via the ConditionPathExists . The systemd just skips services with false conditions, but the dependency is retained.
The main reason to serialize these two services via dependency is to have only one service for the sound state restore (alsa-restore) for other systemd units. Fedora uses this in canberra-system-bootup.service for an example. Perhaps this dependency may be solved using a new target, but it seems more complicated than use 2 services at the moment for me.
Thanks for the comment. We've realised our assumption was wrong and I have taken this patch down.
http://patch-tracker.debian.org/patch/series/view/alsa-tools/1.0.27-2/envy24... This one is to be discussed. envy24control currently creates a visible directory in $HOME, which is quite unacceptable. This patch just moves the directory to a dotdir, but an upgrade path might need to be coded. I would just move the thing away.
As Mark suggested, the envy24control should look for the old config files, too.
I probably won't have time to do this, though.