Re: Matplotlib 3.10.0 for trixie?

[Alexandre Detiste <alexandre.detiste@gmail.com>]

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 <jay@jp-hosting.net> a écrit :
>
> Hi Nilesh, Alex,
>
> Responding to the first point only, at the moment:
>
> On Sat, 12 Apr 2025 at 07:39, Nilesh Patra <nilesh@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