| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This is the correct behavior, but it was overlooked when aptitude
patterns where ported. I remember wondering about this, but I checked
the aptitude code and saw a check that CurrentVer != 0 or something
and then apparently did not notice another implementation for version
matching.
|
| |
|
|
|
|
|
|
| |
We needed a fake dpkg in our status file for dpkg --assert-multi-arch to
work in the past, but recent dpkg versions do not require this anymore,
so we can remove this somewhat surprising hackery in favour of better
hidden hackery we only use if we work with an older dpkg (e.g. on
current Debian stable).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously (and still in cacheset), patterns where only allowed to
start with ? or ~, which ignores the fact that a pattern might just
as well start with a negation, such a !~nfoo.
Also, we ignored the --regex flag if it looked like this, which
was somewhat bad.
Let's change this all:
* If --regex is given, arguments are always interpreted as regex
* If it is a valid package wildcard (name or * characters), then
it will be interpreted as a wildcard - this set of characters is
free from meaningful overlap with patterns.
* Otherwise, the argument is interpreted as a pattern.
For a future version, we need to adapt parsing for cacheset and
list to use a common parser, to avoid differences in their
interpretation. Likely, this code will go into the pattern parser,
such that it generates a pattern given a valid fnmatch argument
for example.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reinstate * wildcards as they are safe to use, but do not allow any
other special characters such as ? or [].
Notably, ? would overlap with patterns, and [] might overlap with
future pattern extensions (alternative bracketing style), it's also
hard to explain.
Closes: #953531
LP: #1872200
|
| |
|
|
|
|
|
|
| |
Packages from third-party sources do not always follow the established
patterns of more properly maintained archives. In that case it was a
driver package for a scanner&printer device which has only a minimum of
info attached, but also minimal non-installed packages do not include
sections, so we really shouldn't assume their availability.
|
| |
|
|
|
| |
This is the first step. Next step will be to add warnings to
apt-get and then remove support there as well.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is pure syntactic sugar - ?narrow does not exist in the
abstract syntax.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This matches any package that does not have versions.
|
| |
|
|
|
|
| |
The ?exact-name pattern matches the name exactly, there is
no substring matching going on, or any regular expression
or fnmatch magic.
|
| |
|
|
|
|
| |
This matches all packages where at least one of the versions
is marked essential; or well, whenver apt considers a package
essential.
|
| |
|
|
|
| |
This matches all packages that have broken dependencies in the
installed version or the version selected for install.
|
| |
|
|
|
|
| |
These two are mutually exclusive states of installed-ness. And
?installed package is fully unpacked and configured; a ?config-files
package only has config files left.
|
| |
|
|
|
|
|
|
|
| |
These match packages that have no version in a repository, or
where an upgrade is available. Notably,
?and(?obsolete,?upgradable) == ?false
because an upgradable package is by definition not obsolete.
|
| |
|
|
|
|
| |
These patterns allow you to identify automatically installed
packages, as well as automatically installed packages that are
no longer reachable from the manually installed ones.
|
| |
|
|
|
|
|
| |
This implements the basic logic patterns:
?and ?false ?not ?or ?true
and the basic package patterns:
?architecture ?name ?x-name-fnmatch
|
|
|
This adds a transformation from parse tree into a CacheFilter and
connects it with cachesets and the apt list command.
|
