Advertisement
Guest User

Untitled

a guest
Oct 15th, 2019
90
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 1.52 KB | None | 0 0
  1.  
  2. SPECIFYING PACKAGES
  3. Many commands take a <package-spec> parameter that selects a package for the operation. DNF looks for interpretations of the parameter from the most commonly used meanings to the least, that is it tries to see if the given
  4. spec fits one of the following patterns (in decreasing order of priority):
  5.  
  6. · name.arch
  7.  
  8. · name
  9.  
  10. · name-[epoch:]version-release.arch
  11.  
  12. · name-[epoch:]version-release
  13.  
  14. · name-[epoch:]version
  15.  
  16. Note that name can in general contain dashes (e.g. package-subpackage).
  17.  
  18. Failing to match the input argument to an existing package name based on the patterns above, DNF tries to see if the argument matches an existing provide.
  19.  
  20. By default, if multiple versions of the selected package exist in the repository, the most recent version suitable for the given operation is used. If the selected package exists for multiple architectures, the packages which
  21. best match the system's architecture will be preferred. The name specification is case-sensitive, globbing characters "?, * and [ are allowed and trigger shell-like glob matching. If a globbing character is present in name,
  22. DNF expands given name first and consequently selects all packages matching the expanded <package-spec>.
  23.  
  24. <package-name-spec> is similar to <package-spec> except the provides matching is never attempted there.
  25.  
  26. <package-installed-specs> is similar to <package-specs> except it considers only installed packages.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement