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

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

[Jaroslav Kysela]

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=93e03bdc2a3dcd5d12516f5de78e14d88a32ff2c
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=78505dccd23546cc77e5221cb21c01325bc0138d

						Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: alsa-lib: add-on configs directory changed to /etc/alsa/conf.d

[Takashi Iwai]

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

Re: alsa-lib: add-on configs directory changed to /etc/alsa/conf.d

[Jaroslav Kysela]

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


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: alsa-lib: add-on configs directory changed to /etc/alsa/conf.d

[Takashi Iwai]

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

Re: alsa-lib: add-on configs directory changed to /etc/alsa/conf.d

[Jaroslav Kysela]

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@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: 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