[alsa-devel] alsa-lib: add-on configs directory changed to /etc/alsa/conf.d

[Takashi Iwai]

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