Hi, Trixie has been released. We/you can proceed with the plan to remove the current unpatched/verbatim /etc/matplotlibrc
Greetings Alexandre Le sam. 12 avr. 2025 à 14:48, James Addison <[email protected]> a écrit : > > Hi Nilesh, Alex, > > Responding to the first point only, at the moment: > > On Sat, 12 Apr 2025 at 07:39, Nilesh Patra <[email protected]> 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
