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 -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
