[alsa-devel] alsa-lib: add-on configs directory changed to /etc/alsa/conf.d
Hi,
I pushed two commits to the alsa-lib package which changes the default location for the add-on config files to /etc/alsa/conf.d from /usr/share/alsa/alsa.conf.d . The reason is to follow the scheme like in other packages. Also, the users might want to change or disable contents in those 'default' files.
Example paths from other packages:
# find /etc -type d -name conf.d /etc/fonts/conf.d /etc/NetworkManager/conf.d /etc/libblockdev/conf.d /etc/sssd/conf.d /etc/httpd/conf.d
Commmits:
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=93e03bdc2a3dcd5d12516... http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=78505dccd23546cc77e52...
Jaroslav
On Wed, 04 Apr 2018 10:12:50 +0200, Jaroslav Kysela wrote:
Hi,
I pushed two commits to the alsa-lib package which changes the default location for the add-on config files to /etc/alsa/conf.d from /usr/share/alsa/alsa.conf.d . The reason is to follow the scheme like in other packages. Also, the users might want to change or disable contents in those 'default' files.
Example paths from other packages:
# find /etc -type d -name conf.d /etc/fonts/conf.d /etc/NetworkManager/conf.d /etc/libblockdev/conf.d /etc/sssd/conf.d /etc/httpd/conf.d
How about evaluating both paths, with preference of /etc over /usr/share? The change to allow only /etc would break the existing alsa-plugins packaging, for example, which still may put the config to /usr/share/alsa/conf.d.
In general, /usr/share is the place for global setups while /etc for local machines. So it's more natural to put the package default setup to /usr/share while allowing overriding it via /etc. You can imagine /usr/share is shared via NFS. If anything different is necessary, you put it in /etc.
thanks,
Takashi
Dne 10.4.2018 v 09:16 Takashi Iwai napsal(a):
On Wed, 04 Apr 2018 10:12:50 +0200, Jaroslav Kysela wrote:
Hi,
I pushed two commits to the alsa-lib package which changes the default location for the add-on config files to /etc/alsa/conf.d from /usr/share/alsa/alsa.conf.d . The reason is to follow the scheme like in other packages. Also, the users might want to change or disable contents in those 'default' files.
Example paths from other packages:
# find /etc -type d -name conf.d /etc/fonts/conf.d /etc/NetworkManager/conf.d /etc/libblockdev/conf.d /etc/sssd/conf.d /etc/httpd/conf.d
How about evaluating both paths, with preference of /etc over /usr/share? The change to allow only /etc would break the existing alsa-plugins packaging, for example, which still may put the config to /usr/share/alsa/conf.d.
In general, /usr/share is the place for global setups while /etc for local machines. So it's more natural to put the package default setup to /usr/share while allowing overriding it via /etc. You can imagine /usr/share is shared via NFS. If anything different is necessary, you put it in /etc.
From the packager perspective, it makes more sense to have only
/etc/alsa/conf.d in the global alsa.conf and make symlinks to /usr/share like fontconfig does (/etc/fonts/conf.d). The users will modify only /etc contents as they should for the non-standard configurations. This variant also looks to me more straight for users. Opinions?
Thanks, Jaroslav
On Mon, 16 Apr 2018 15:01:33 +0200, Jaroslav Kysela wrote:
Dne 10.4.2018 v 09:16 Takashi Iwai napsal(a):
On Wed, 04 Apr 2018 10:12:50 +0200, Jaroslav Kysela wrote:
Hi,
I pushed two commits to the alsa-lib package which changes the default location for the add-on config files to /etc/alsa/conf.d from /usr/share/alsa/alsa.conf.d . The reason is to follow the scheme like in other packages. Also, the users might want to change or disable contents in those 'default' files.
Example paths from other packages:
# find /etc -type d -name conf.d /etc/fonts/conf.d /etc/NetworkManager/conf.d /etc/libblockdev/conf.d /etc/sssd/conf.d /etc/httpd/conf.d
How about evaluating both paths, with preference of /etc over /usr/share? The change to allow only /etc would break the existing alsa-plugins packaging, for example, which still may put the config to /usr/share/alsa/conf.d.
In general, /usr/share is the place for global setups while /etc for local machines. So it's more natural to put the package default setup to /usr/share while allowing overriding it via /etc. You can imagine /usr/share is shared via NFS. If anything different is necessary, you put it in /etc.
From the packager perspective, it makes more sense to have only
/etc/alsa/conf.d in the global alsa.conf and make symlinks to /usr/share like fontconfig does (/etc/fonts/conf.d). The users will modify only /etc contents as they should for the non-standard configurations. This variant also looks to me more straight for users. Opinions?
Well, I'm not sure. First of all, is this kind of config style (symlinking from /usr/share to /etc) generic? I don't know of anything else than fontconfig.
And, the case of fontconfig looks is somehow hackish: it prepares the available configs in /usr/share/fontconfig/conf.avail/*, and symlinking to a differently named directory, /etc/fonts/conf.d/*.
I think other cases are classified to a few different types:
- systemd-style: there are two directories, /usr/share/foo/xxx.d/ and /etc/foo/xxx.d/. Read from both directories, but /etc is preferred. i.e. if a same file name is present in both /etc and /usr/share, the former is taken and the latter is ignored.
- both /usr/share and /etc directories are evaluated, often in the order of /etc preference, but no conflict check like systemd.
- only either /etc or /usr/share
Basically fontconfig belongs to the last type but with some symlink hacks. Honestly speaking, I never understand why they took such an approach...
Actually, I'm not objecting to addition of /etc. But, as already mentioned, a slight concern is the case where another package (e.g. alsa-plugins-xyz) adds /usr/share/alsa/conf.d/*.conf. With the current proposal, we'll silently break. And the situation won't change if we follow the fontconfig pattern.
thanks,
Takashi
Dne 16.4.2018 v 20:08 Takashi Iwai napsal(a):
On Mon, 16 Apr 2018 15:01:33 +0200, Jaroslav Kysela wrote:
Dne 10.4.2018 v 09:16 Takashi Iwai napsal(a):
On Wed, 04 Apr 2018 10:12:50 +0200, Jaroslav Kysela wrote:
Hi,
I pushed two commits to the alsa-lib package which changes the default location for the add-on config files to /etc/alsa/conf.d from /usr/share/alsa/alsa.conf.d . The reason is to follow the scheme like in other packages. Also, the users might want to change or disable contents in those 'default' files.
Example paths from other packages:
# find /etc -type d -name conf.d /etc/fonts/conf.d /etc/NetworkManager/conf.d /etc/libblockdev/conf.d /etc/sssd/conf.d /etc/httpd/conf.d
How about evaluating both paths, with preference of /etc over /usr/share? The change to allow only /etc would break the existing alsa-plugins packaging, for example, which still may put the config to /usr/share/alsa/conf.d.
In general, /usr/share is the place for global setups while /etc for local machines. So it's more natural to put the package default setup to /usr/share while allowing overriding it via /etc. You can imagine /usr/share is shared via NFS. If anything different is necessary, you put it in /etc.
From the packager perspective, it makes more sense to have only
/etc/alsa/conf.d in the global alsa.conf and make symlinks to /usr/share like fontconfig does (/etc/fonts/conf.d). The users will modify only /etc contents as they should for the non-standard configurations. This variant also looks to me more straight for users. Opinions?
Well, I'm not sure. First of all, is this kind of config style (symlinking from /usr/share to /etc) generic? I don't know of anything else than fontconfig.
And, the case of fontconfig looks is somehow hackish: it prepares the available configs in /usr/share/fontconfig/conf.avail/*, and symlinking to a differently named directory, /etc/fonts/conf.d/*.
The /usr/share fontconfig files are called as templates and it makes sense to me.
I think other cases are classified to a few different types:
- systemd-style: there are two directories, /usr/share/foo/xxx.d/ and /etc/foo/xxx.d/. Read from both directories, but /etc is preferred. i.e. if a same file name is present in both /etc and /usr/share, the former is taken and the latter is ignored.
If I imagine the code which is required to read both directories, compare the clashes and do all those extra stuff I think that the symlinks are more nice.
both /usr/share and /etc directories are evaluated, often in the order of /etc preference, but no conflict check like systemd.
only either /etc or /usr/share
Basically fontconfig belongs to the last type but with some symlink hacks. Honestly speaking, I never understand why they took such an approach...
Most of packages is using only /etc.
The systemd is doing the exactly similar thing. Just look to the /etc/systemd/system tree. Except that those files are managed at runtime and they are not a part of a package.
Actually, I'm not objecting to addition of /etc. But, as already mentioned, a slight concern is the case where another package (e.g. alsa-plugins-xyz) adds /usr/share/alsa/conf.d/*.conf. With the current proposal, we'll silently break. And the situation won't change if we follow the fontconfig pattern.
The question is, if we do have such packages. The only problem might be to use old plugin packages with the updated alsa-lib's global config, but it is really a rare case. Usually, all ALSA packages are updated in the sync and it's really easy to symlink/include/copy files from /usr/share to /etc or include again /usr/share directory from /etc config files if users use something special.
If I don't miss something, only the pulse plugin package has (had) an own config. We have also template configs for other plugins in Fedora which I pushed with more generic changes to the alsa-plugins package now.
I would assume the minimal impact for the current installations with this change.
From my side the whole story for this change began when I was notified
that the /usr/share path should not contain files to be modified by users (in the standard usage).
Jaroslav
On Mon, 16 Apr 2018 21:34:51 +0200, Jaroslav Kysela wrote:
Dne 16.4.2018 v 20:08 Takashi Iwai napsal(a):
On Mon, 16 Apr 2018 15:01:33 +0200, Jaroslav Kysela wrote:
Dne 10.4.2018 v 09:16 Takashi Iwai napsal(a):
On Wed, 04 Apr 2018 10:12:50 +0200, Jaroslav Kysela wrote:
Hi,
I pushed two commits to the alsa-lib package which changes the default location for the add-on config files to /etc/alsa/conf.d from /usr/share/alsa/alsa.conf.d . The reason is to follow the scheme like in other packages. Also, the users might want to change or disable contents in those 'default' files.
Example paths from other packages:
# find /etc -type d -name conf.d /etc/fonts/conf.d /etc/NetworkManager/conf.d /etc/libblockdev/conf.d /etc/sssd/conf.d /etc/httpd/conf.d
How about evaluating both paths, with preference of /etc over /usr/share? The change to allow only /etc would break the existing alsa-plugins packaging, for example, which still may put the config to /usr/share/alsa/conf.d.
In general, /usr/share is the place for global setups while /etc for local machines. So it's more natural to put the package default setup to /usr/share while allowing overriding it via /etc. You can imagine /usr/share is shared via NFS. If anything different is necessary, you put it in /etc.
From the packager perspective, it makes more sense to have only
/etc/alsa/conf.d in the global alsa.conf and make symlinks to /usr/share like fontconfig does (/etc/fonts/conf.d). The users will modify only /etc contents as they should for the non-standard configurations. This variant also looks to me more straight for users. Opinions?
Well, I'm not sure. First of all, is this kind of config style (symlinking from /usr/share to /etc) generic? I don't know of anything else than fontconfig.
And, the case of fontconfig looks is somehow hackish: it prepares the available configs in /usr/share/fontconfig/conf.avail/*, and symlinking to a differently named directory, /etc/fonts/conf.d/*.
The /usr/share fontconfig files are called as templates and it makes sense to me.
Right, they are templates. So they have to be copied or symlinked. That is, we'll have two files mandatorily, which looks messy to me.
I think other cases are classified to a few different types:
- systemd-style: there are two directories, /usr/share/foo/xxx.d/ and /etc/foo/xxx.d/. Read from both directories, but /etc is preferred. i.e. if a same file name is present in both /etc and /usr/share, the former is taken and the latter is ignored.
If I imagine the code which is required to read both directories, compare the clashes and do all those extra stuff I think that the symlinks are more nice.
That's true.
both /usr/share and /etc directories are evaluated, often in the order of /etc preference, but no conflict check like systemd.
only either /etc or /usr/share
Basically fontconfig belongs to the last type but with some symlink hacks. Honestly speaking, I never understand why they took such an approach...
Most of packages is using only /etc.
The systemd is doing the exactly similar thing. Just look to the /etc/systemd/system tree. Except that those files are managed at runtime and they are not a part of a package.
The situation of systemd is also chaotic. The udev takes the approach I mentioned, while /etc/systemd/system has some automatic generation. And many are not in /usr/share but rather in /usr/lib. But one thing is that they tend to put the packaging stuff in /usr, and leave /etc for the system-local setup. And, IIRC, XDG autostart & co take the similar approach (it also allows ~/.config to override, too).
Actually, I'm not objecting to addition of /etc. But, as already mentioned, a slight concern is the case where another package (e.g. alsa-plugins-xyz) adds /usr/share/alsa/conf.d/*.conf. With the current proposal, we'll silently break. And the situation won't change if we follow the fontconfig pattern.
The question is, if we do have such packages. The only problem might be to use old plugin packages with the updated alsa-lib's global config, but it is really a rare case. Usually, all ALSA packages are updated in the sync and it's really easy to symlink/include/copy files from /usr/share to /etc or include again /usr/share directory from /etc config files if users use something special.
That's true. OTOH, it's also equally easy just to add a path /etc/alsa/conf.d to the default config while keeping the old /usr/share/alsa/alsa.conf.d. It'll be basically a one-liner change.
If I don't miss something, only the pulse plugin package has (had) an own config. We have also template configs for other plugins in Fedora which I pushed with more generic changes to the alsa-plugins package now.
I would assume the minimal impact for the current installations with this change.
From my side the whole story for this change began when I was notified that the /usr/share path should not contain files to be modified by users (in the standard usage).
Yeah, I understand this part. But I wonder what's wrong with a simpler approach, just add another path /etc/alsa/conf.d to the existing alsa.conf.
thanks,
Takashi
participants (2)
-
Jaroslav Kysela -
Takashi Iwai