[Bug 1872200] Re: apt does not accept globs and regexes in some cases

[Julian Andres Klode]

** Description changed:

+ [Impact]
+ Users can't use * wildcards anymore in focal, except by accident in apt list.
+ 
+ For apt list, we now start restricting wildcard syntax to the same
+ syntax install now accepts, and at the same time we remove the
+ restrictions on which patterns are accepted (which only accepted
+ patterns starting in ~ or ?), so !~napt now works, and does not
+ accidentally match as a wildcard.
+ 
+ 
+ [Test case]
+ 
+ Test that * wildcards work for both install and list, and test that a ?
+ wildcard does not.
+ 
+ We included autopkgtests for those:
+ 
+ #### BEGIN TESTS #####
+ 
+ # * wildcards should still work
+ testsuccessequal "Listing...
+ automatic1/now 1.0 i386 [installed,local]
+ automatic2/now 1.0 i386 [installed,local]" apt list 'automatic*'
+ 
+ testfailureequal "Reading package lists...
+ Building dependency tree...
+ Reading state information...
+ Note, selecting 'automatic1' for glob 'automatic*'
+ Note, selecting 'automatic2' for glob 'automatic*'
+ automatic1 is already the newest version (1.0).
+ automatic1 set to manually installed.
+ automatic2 is already the newest version (1.0).
+ automatic2 set to manually installed.
+ You might want to run 'apt --fix-broken install' to correct these.
+ The following packages have unmet dependencies:
+  broken : Depends: does-not-exist but it is not installable
+ E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution)." apt install -s 'automatic*'
+ 
+ # other wildcards should fail
+ 
+ testfailureequal "Listing...
+ E: input:0-10: error: Expected pattern
+    automatic?
+    ^^^^^^^^^^" apt list 'automatic?'
+ 
+ testfailureequal "Reading package lists...
+ Building dependency tree...
+ Reading state information...
+ E: Unable to locate package automatic?" apt install -s 'automatic?'
+ 
+ 
+ #### END TESTS #####
+ 
+ Also it might be worth checking that apt list !~napt works. This used to
+ produce an empty list, as it was accidentally matched as a wildcard and
+ produced no result - now it produces every package whose name does not
+ contain "apt".
+ 
+ 
+ [Regression potential]
+ The changes only affect interactive users, as apt(8) is not stable for in-script use, hence they can fix up their command-line if it stops working for them (though, really, more should work now).
+ 
+ No scripts will be broken :)
+ 
+ [Squashed in changes]
+ The SRU also fixes potential build failures by correctly prefxing nullptr_t with the std:: namespace, and includes updated Dutch documentation.
+ 
+ [Original bug report]
  Observed with Ubuntu 20.04 Beta.
  
  apt remove 'mypackage*' does not remove all installed packages starting
  with “mypackage”.  Instead:
  
  $ sudo apt remove 'mypackage*'
  Reading package lists... Done
- Building dependency tree       
+ Building dependency tree
  Reading state information... Done
  E: Unable to locate package mypackage*
  
  However:
  
  $ sudo apt list --installed 'mypackage*'
  Listing... Done
  mypackage-data-v1/focal,focal,now 0.3.2-5build1 all [installed,automatic]
  mypackage1/focal,now 0.3.2-5build1 amd64 [installed]

** Also affects: apt (Ubuntu Groovy)
   Importance: Undecided
       Status: Fix Committed

** Also affects: apt (Ubuntu Focal)
   Importance: Undecided
       Status: New

** Changed in: apt (Ubuntu Focal)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1872200

Title:
  apt does not accept globs and regexes in some cases

Status in apt package in Ubuntu:
  Fix Committed
Status in apt source package in Focal:
  Triaged
Status in apt source package in Groovy:
  Fix Committed

Bug description:
  [Impact]
  Users can't use * wildcards anymore in focal, except by accident in apt list.

  For apt list, we now start restricting wildcard syntax to the same
  syntax install now accepts, and at the same time we remove the
  restrictions on which patterns are accepted (which only accepted
  patterns starting in ~ or ?), so !~napt now works, and does not
  accidentally match as a wildcard.

  
  [Test case]

  Test that * wildcards work for both install and list, and test that a
  ? wildcard does not.

  We included autopkgtests for those:

  #### BEGIN TESTS #####

  # * wildcards should still work
  testsuccessequal "Listing...
  automatic1/now 1.0 i386 [installed,local]
  automatic2/now 1.0 i386 [installed,local]" apt list 'automatic*'

  testfailureequal "Reading package lists...
  Building dependency tree...
  Reading state information...
  Note, selecting 'automatic1' for glob 'automatic*'
  Note, selecting 'automatic2' for glob 'automatic*'
  automatic1 is already the newest version (1.0).
  automatic1 set to manually installed.
  automatic2 is already the newest version (1.0).
  automatic2 set to manually installed.
  You might want to run 'apt --fix-broken install' to correct these.
  The following packages have unmet dependencies:
   broken : Depends: does-not-exist but it is not installable
  E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution)." apt install -s 'automatic*'

  # other wildcards should fail

  testfailureequal "Listing...
  E: input:0-10: error: Expected pattern
     automatic?
     ^^^^^^^^^^" apt list 'automatic?'

  testfailureequal "Reading package lists...
  Building dependency tree...
  Reading state information...
  E: Unable to locate package automatic?" apt install -s 'automatic?'

  
  #### END TESTS #####

  Also it might be worth checking that apt list !~napt works. This used
  to produce an empty list, as it was accidentally matched as a wildcard
  and produced no result - now it produces every package whose name does
  not contain "apt".

  
  [Regression potential]
  The changes only affect interactive users, as apt(8) is not stable for in-script use, hence they can fix up their command-line if it stops working for them (though, really, more should work now).

  No scripts will be broken :)

  [Squashed in changes]
  The SRU also fixes potential build failures by correctly prefxing nullptr_t with the std:: namespace, and includes updated Dutch documentation.

  [Original bug report]
  Observed with Ubuntu 20.04 Beta.

  apt remove 'mypackage*' does not remove all installed packages
  starting with “mypackage”.  Instead:

  $ sudo apt remove 'mypackage*'
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  E: Unable to locate package mypackage*

  However:

  $ sudo apt list --installed 'mypackage*'
  Listing... Done
  mypackage-data-v1/focal,focal,now 0.3.2-5build1 all [installed,automatic]
  mypackage1/focal,now 0.3.2-5build1 amd64 [installed]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1872200/+subscriptions