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, aster...@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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
