| Age | Commit message (Collapse) | Author |
|---|
|
This matches the definitions used by dpkg.
Closes: #953527
|
|
apt-helper: Add analyze-pattern helper
See merge request apt-team/apt!113
|
|
Closes: #953804
|
|
While merging apt-pkg and apt-inst libraries the codepath of handling
deb files in apt-pkg was adapted to use the 'old' code from apt-inst
instead of fork&exec of dpkg-deb -I. The information we get this way
forms the main part of the package stanza, but we add a few
semi-optional fields to the stanza to make it look and work more
like a stanza we got from a repository.
Just be careful with the area where these two parts touch as if,
hypothetically, we would stip all newlines around the parts,
but forget to add a newline between them later, the two lines around
the merge would stick a bit too close together forming one which could
result in fun parsing errors if this merged line was previously e.g. a
well-formed Depends line and has now extra fluff attached.
This codepath has a history with too many newlines (#802553) though,
so how likely is it really that it will some day lack one you may ask.
References: 6089a4b17c61ef30b2efc00e270b0907f51f352a
|
|
The analyze-pattern helper parses a pattern and then renders
the parsed pattern, allowing you to analyze how the parser
interpreted the string.
This can be useful to analyse (yes, analyse-pattern also works)
why a pattern is different from aptitude or why it does not
work as expected.
It can also be used to check if apt has pattern support, although
that will miss out on the version shipped in eoan, but who really
cares about that longer term anyway?
|
|
Extract the code, and reformat it with clang-format so we can
modify it.
|
|
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.
|
|
|
|
Pu/improve locking msgs
See merge request apt-team/apt!111
|
|
Showing a percentage for a timeout is pretty non-standard. Rework the
progress class so it can show an absolute progress (currently hardcoded
to use seconds as a unit). If there is a timeout (aka if it's not the
maximum long long unsigned -1llu), then show the timeout, otherwise
just count up seconds, e.g.
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1/120s
or
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1s
Also improve the error message to use "Waiting for cache lock: %s" instead of "... (%s)", as having
multiple sentences inside parenthesis is super weird, as is having two closing parens.
We pass the information via _config, as that's reasonably easy and avoids
ABI hackage. It also provides an interesting debugging tool for other
kinds of progress.
|
|
This improves the locking message, getting rid of useless details. If
we have a process holding the lock, we got that because the lock is
being hold by it, so there's no point telling the people the reason
for not getting the lock is the EAGAIN error and displaying its
strerrror().
|
|
|
|
|
|
|
|
|
|
Pu/wait lock
See merge request apt-team/apt!109
|
|
apt-pkg: default visibility to hidden
See merge request apt-team/apt!108
|
|
This is a rework of !6 with additional stuff for the frontend
lock, so we can lock the frontend lock and then keep looping
over dpkg lock.
|
|
|
|
Pu/misc
See merge request apt-team/apt!107
|
|
Remove the operator= from Container_iterator, as it was basically
just the default anyway, and add copy constructors to *Interface
that match their operator=.
Tried adding copy constructor to Container_iterator, but that only
made things worse.
|
|
|
|
No sensible file should include these, but even insensible files do not
gain unfair advantages with it as this parser does not deal with
security critical files before they haven't passed other checks like
signatures or hashsums.
The problem is that the parser accepts and parses empty tag names
correctly, but does not store the data parsed which will effect later
passes over the data resulting e.g. in the following tag containing
the name and value of the previous (empty) tag, its own tagname and its
own value or a crash due to an attempt to access invalid memory
depending on who passes over the data and what is done with it.
This commit fixes both, the incidient of the crash reported by
Anatoly Trosinenko who reproduced it via apt-sortpkgs:
| $ cat /tmp/Packages-null
| 0:
| PACKAGE:0
|
| :
| PACKAGE:
|
| PACKAGE::
| $ apt-sortpkgs /tmp/Packages-null
and the deeper parsing issue shown by the included testcase.
Reported-By: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
References: 8710a36a01c0cb1648926792c2ad05185535558e
|
|
|
|
Cleanup ABI - make stuff virtual, etc
See merge request apt-team/apt!106
|
|
|
|
Only expose the locations of the hasthables if APT_COMPILING_APT
is set.
|
|
|
|
|
|
These were hidden behind the d-pointer previously.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pu/tagfile hardening
See merge request apt-team/apt!104
|
|
|
|
|
|
|
|
This is not supposed to be done this way, but frankly, since we
abstract away the backend, there's not much else we can do here.
Closes: #949074
|
|
Type-safe cache / map_pointer
See merge request apt-team/apt!105
|
|
This allows us to extend those in-cache objects with more
data later on without breaking the ABI.
Reserve 12 pointers for private data in the pkgCache class,
and double the size of pools to 24.
|
|
When converting a long offset to a uint32_t to be stored in
the map, check that this is safe to do. If the offset is
negative, or we lose data in the conversion, we lost.
|
|
Instead of just using uint32_t, which would allow you to
assign e.g. a map_pointer<Version> to a map_pointer<Package>,
use our own smarter struct that has strict type checking.
We allow creating a map_pointer from a nullptr, and we allow
comparing map_pointer to nullptr, which also deals with comparisons
against 0 which are often used, as 0 will be implictly converted
to nullptr.
|
|
|
|
This is a first step to a type safe cache, adding typing
information everywhere. Next, we'll replace map_pointer<T>
implementation with a type safe one.
|
