Hi Nilesh, Alex, Responding to the first point only, at the moment:
On Sat, 12 Apr 2025 at 07:39, Nilesh Patra <nil...@debian.org> wrote: > [ ... snip ... ] > 1. matplotlib has historically shipped /etc/matploblibrc to force tkagg and > patched the code > to use this if there are no user defined rc files see [1]. However, this was > not > handled properly via maintscripts so that'd mean over-writing user-modified > /etc/matplotlibrc. Ah; what is the problem related to the maintscripts? The /etc/matplotlibrc file is considered a config file by apt/dpkg (it is not removed unless a purge is requested), so I was hoping that shipping a default/unmodified matplotlibrc in an updated 3.10 upload (as Alex suggests in his thread) would provide a useful additional conflict-resolution step for anyone who has modified theirs. > The backend detection logic is now better and I feel we should get rid of the > "yield '/etc/matplotlibrc'" in > [1] and also stop shipping the conffile both and add in a rm_conffile to > remove previously > installed /etc/matplotlibrc. I don't have a strong opinion about this part, although when in sysadmin mode, I do tend to go looking in /etc first to find config files. On the other hand, we wouldn't be the first package to read config files from elsewhere on the filesystem - pipewire springs to mind as another case where default config files are located under /usr/share, for example. > Probably also a d/NEWS to inform the sysadmin that this no longer works. It > does not make > sense to me for a python lib to have a conffile. +1 to a NEWS entry. I'm not so sure about removing the conffile entirely yet, though. I think it may be safer to treat it as a feature deprecation, allowing time for feedback about any use cases that seem to require it and/or for users to migrate to alternatives. Regards, James
