[asterisk-dev] Deprecating users.conf

[asterisk at phreaknet.org]

On 6/30/2023 8:32 AM, Jaco Kroon wrote:
> On 2023/06/30 14:19, Sean Bright wrote:
>> On 6/30/2023 7:45 AM, asterisk at phreaknet.org wrote:
>>> I've put up a PR to deprecate users.conf[1], following a
>>> discussion earlier this year about this, but I think that was on IRC so
>>> wanted to discuss here as well.
>> Apologies - I realized after initially commenting on the PR that I 
>> could have stated my objection immediately rather than direct you here.
>>
>> I and my users are using users.conf for nearly every install and 
>> removing support for it would be disruptive to 100s of installs.

Do you mind sharing what these use cases are and what 
functionality/modules you're using it for? As Henning said, maybe there 
is a better way. Either way, it would be good to understand what anyone 
might currently be doing with it.

>> I've also had some people reach out to me off-list expressing their 
>> concerns with it being removed.

Do you mind sharing what these concerns are exactly?

>> I am willing to take over all support for users.conf going forward. I 
>> can update the module deprecation page¹ indicating I am the maintainer.
>>
>> If the deprecation warning remains I would need to be able to silence 
>> it with a command line flag or an option in asterisk.conf.

This would be silly, for a couple reasons:
- If something is deprecated, the idea is that it will be removed 
eventually. If it's not going to be removed, then it doesn't really make 
sense to deprecate to me. Adding an option is just temporarily adding 
integration for something that will be removed soon enough, otherwise.
- The fact that users.conf exists already currently throws warnings for 
users not using it. If it's not on track for deprecation, then we should 
at least silence these warnings so non-users are not confused.
- If this were really practical, then I would also like to see a similar 
flag or option to disable the deprecating warnings for app_adsiprog, 
app_getcpeid, and res_adsi, especially since those are not being 
removed, as those confuse my users. Currently, I patch the source on 
install to remove the deprecation warnings for these 3 modules. If you 
really "need" to silence something, you could theoretically do the same.

> I don't have a specific objection against removal, we used this 
> instead of dahdi.conf since we could get stuff working for dahdi 
> channels that we could not get working in dahdi.conf.
(I'm assuming you mean chan_dahdi.conf, not dahdi.conf)

> Can't remember the details but it has remained.  Fairly certain that I 
> can dig that up again, and either get it migrated or can make a plan 
> to get it sorted so that we can support it. 

Thanks for bringing this up. Do you know what is not working exactly? 
Independent of this issue, we should obviously get that fixed and all 
sorted out.

  NA