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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
