Bug#1040300: plocate: Transition from mlocate during upgrade to Bookworm introduced breaking changes

2023-07-05 Thread Larsen

Because you would have to worry about deduplication of the results,
which is nontrivial to do without incurring unbounded memory costs
and/or messing up the expected ordering of the output. In short,
it's not worth it.


Well, I'd expect no distinct ordering so the internal result could be
piped to "sort --unique" to get rid of duplicates (I guess).
If this (ordering) was documented, I assume that many users would still
prefer running plocate instead of mlocate due to plocate's speed.



Bug#1040300: plocate: Transition from mlocate during upgrade to Bookworm introduced breaking changes

2023-07-05 Thread Steinar H. Gunderson
On Wed, Jul 05, 2023 at 12:41:51PM +0200, Larsen wrote:
> ...and then output the results for all files at once, leading to the same
> behaviour as mlocate while being much faster.

Because you would have to worry about deduplication of the results,
which is nontrivial to do without incurring unbounded memory costs
and/or messing up the expected ordering of the output. In short,
it's not worth it.

/* Steinar */
-- 
Homepage: https://www.sesse.net/



Bug#1040300: plocate: Transition from mlocate during upgrade to Bookworm introduced breaking changes

2023-07-05 Thread Larsen

It is correct that there is no OR-mode, nor is any planned (it is a major
pain to implement performantly and correctly, and fairly niche).


Why not run plocate with every parameter internally?

For example:
  plocate --use-OR file1 file2 file3

Would take all the arguments and internally run...
  plocate file1
  plocate file2
  plocate file3

...and then output the results for all files at once, leading to the same
behaviour as mlocate while being much faster. And even if it wasn't faster
as mlocate in this case, who cares?


Larsen



Bug#1040300: plocate: Transition from mlocate during upgrade to Bookworm introduced breaking changes

2023-07-04 Thread Steinar H. Gunderson
On Tue, Jul 04, 2023 at 11:22:15AM +0200, Steinar H. Gunderson wrote:
>> Instead of using this:
>>   locate --existing dpkg-dist dpkg-new dpkg-old dpkg-bak ucf-dist ucf-new
>> ucf-old | egrep -v
>> "dpkg-distaddfile|dpkg_dateien_vor_update_|/var/backup/burp|/root/upgrade_auf_"
> Yes. The “simplest” workaround is probably

I thought of something simpler:

  locate --regex 
'(dpkg-dist|dpkg-new|dpkg-old|dpkg-bak|ucf-dist|ucf-new|ucf-old)' 

but it will be very slow; almost as slow as mlocate.

/* Steinar */
-- 
Homepage: https://www.sesse.net/



Bug#1040300: plocate: Transition from mlocate during upgrade to Bookworm introduced breaking changes

2023-07-04 Thread Steinar H. Gunderson
tags 1040300 + wontfix
thanks

On Tue, Jul 04, 2023 at 10:34:34AM +0200, Larsen wrote:
> with the upgrade from Bullseye to Bookworm, mlocate got replaced by
> plocate. This introduced a breaking change as there is no OR-mode anymore
> on which I rely on in scripts and commands. "apt-listchanges" didn't
> mention this when I performed the upgrade.

It is correct that there is no OR-mode, nor is any planned (it is a major
pain to implement performantly and correctly, and fairly niche). If you wish
to reintroduce mlocate, the transitional package for mlocate will be gone in
bookworm+1 and you are free to maintain it, but note that there is no
upstream development anymore, so you would also be de-facto upstream.

> Instead of using this:
>   locate --existing dpkg-dist dpkg-new dpkg-old dpkg-bak ucf-dist ucf-new
> ucf-old | egrep -v
> "dpkg-distaddfile|dpkg_dateien_vor_update_|/var/backup/burp|/root/upgrade_auf_"
> 
> I now have to run this, which (although certainly could be improved) is
> pretty cumbersome compared to the one liner before.
>   locate --existing dpkg-dist | egrep -v ...
>   locate --existing dpkg-new | egrep -v ...
>   locate --existing dpkg-old | egrep -v ...
>   locate --existing dpkg-bak | egrep -v ...
>   locate --existing ucf-dist | egrep -v ...
>   locate --existing ucf-new | egrep -v ...
>   locate --existing ucf-old  | egrep -v ...

Yes. The “simplest” workaround is probably

  (locate --existing dpkg- ; locate --existing ucf-) | grep -E 
'(dpkg-(dist|new|old|bak)|(ucf-(dist|new|old)))' | egrep -v etc.

/* Steinar */
-- 
Homepage: https://www.sesse.net/



Bug#1040300: plocate: Transition from mlocate during upgrade to Bookworm introduced breaking changes

2023-07-04 Thread Larsen

Package: plocate
Version: 1.1.18-1

Dear Maintainer,

with the upgrade from Bullseye to Bookworm, mlocate got replaced by
plocate. This introduced a breaking change as there is no OR-mode anymore
on which I rely on in scripts and commands. "apt-listchanges" didn't
mention this when I performed the upgrade.

Instead of using this:
  locate --existing dpkg-dist dpkg-new dpkg-old dpkg-bak ucf-dist ucf-new
ucf-old | egrep -v
"dpkg-distaddfile|dpkg_dateien_vor_update_|/var/backup/burp|/root/upgrade_auf_"

I now have to run this, which (although certainly could be improved) is
pretty cumbersome compared to the one liner before.
  locate --existing dpkg-dist | egrep -v ...
  locate --existing dpkg-new | egrep -v ...
  locate --existing dpkg-old | egrep -v ...
  locate --existing dpkg-bak | egrep -v ...
  locate --existing ucf-dist | egrep -v ...
  locate --existing ucf-new | egrep -v ...
  locate --existing ucf-old  | egrep -v ...

Another user reported this problem in November 2021:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999487

There should be at least a parameter to restore the mlocate behaviour.
Same applies to the "--existing" parameter which introduced a breaking
change.