This is not the problem here really. It's the different matching base. Together with the previous versification I also verified that such filenamemangle (like systemd's) don't match anymore. That's equally problematic (if not more!) than the program exiting with an error.
I can agree however you want that it's a bad design, but that has been the specification since the start and it can't change without a format bump. I plan to revert Hugh's commit in the next days to solve this, reopening the previous bug and pending a better fix. On Sat, 20 Nov 2021, 11:02 pm Yadd, <y...@debian.org> wrote: > Le 20/11/2021 à 13:36, Mattia Rizzolo a écrit : > > On Sat, Nov 20, 2021 at 01:14:23PM +0100, Yadd wrote: > >> Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit : > >>> So, effectively, the change broke the specification. > >> > >> It looks like the specification was not good. A filename isn't an URL > > > > Be that as it may, we can't break something like that without a version > > bump, IMHO. > > > > So we need a different fix for #993585. > > > > Either way, I think it's unrelated to your discovery that it could > > potentially overwrite a file, isn't it? > > We could perhaps just warn for now on bad filenamemangle >
