|
Kali Linux Revealed
Pdf ko'rish
|
| bet | 112/174 | | Sana | 15.01.2024 | | Hajmi | 11,68 Mb. | | #137314 |
Bog'liq Kali-Linux-Revealed-2021-editionLeveraging Bug Reports You might sometimes find that a new version of software doesn’t work
at all. This generally happens if the application isn’t particularly popular and hasn’t been tested
enough. The first thing to do is to have a look at the
Kali bug tracker
3
and at the
Debian bug
tracking system
4
at https://bugs.debian.org/
package
, and check whether the problem has already
been reported. If it hasn’t, you should report it yourself (see section
6.3
, “
Filing a Good Bug Report
”
[page 134] for detailed instructions). If it is already known, the bug report and the associated
messages are usually an excellent source of information related to the bug. In some cases, a patch
already exists and has been made available in the bug report itself; you can then recompile a fixed
version of the broken package locally (see section
9.1
, “
Modifying Kali Packages
” [page 228]). In
other cases, users may have found a workaround for the problem and shared their insights about
it in their replies to the report; those instructions may help you work around the problem until a
fix or patch is released. In a best-case scenario, the package may have already been fixed and you
may find details in the bug report.
Downgrading to a Working Version When the problem is a clear regression (where the former
version worked), you can try to downgrade the package. In this case, you will need a copy of the
old version. If you have access to the old version in one of the repositories configured in APT, you
can use a simple one-liner command to downgrade (see section
8.2.2.2
, “
Installing Packages with
APT
” [page 183]). But with Kali’s rolling release, you will usually only find a single version of each
package at any one time.
You can still try to find the old
.deb
file and install it manually with
dpkg
. Old
.deb
files can be
found in multiple places:
• In APT’s cache in
/var/cache/apt/archives/
• In the
pool
directory on your usual Kali mirror (removed and obsolete packages are kept
for three to four days to avoid problems with users not having the latest package indices)
• In
https://snapshot.debian.org/
if the affected package was provided by Debian and
not by Kali; this service keeps historical versions of all Debian packages
3
https://bugs.kali.org/
4
https://bugs.debian.org/
193
Chapter 8 — Debian Package Management
|
| |
