{{Header}}
{{#seo:
|description=Which {{project_name_long}} Debian packages are safe to remove? What is a meta package? What other packages do {{project_name_long}} meta packages install? Which packages should never be removed?
|image=Box-158523640.png
}}
[[File:Box-158523640.png|thumb]]
{{intro|
Which {{project_name_short}} Debian packages are safe to remove? What is a meta package? What other packages do {{project_name_short}} meta packages install? Which packages should never be removed?
}}
= Introduction =
It is safe to run sudo apt autoremove
so long as the specific {{project_name_short}} machine meta package
is kept for the {{non_q_project_name_short}} or {{q_project_name_short}} platform. In other words, these packages should not be in the list of autoremoved packages.
[[About|{{project_name_short}}]]:
* {{project_name_workstation_long}} Xfce: kicksecure-xfce
* {{project_name_workstation_short}} CLI: kicksecure-cli
[[Qubes|{{q_project_name_long}}]]:
* {{q_project_name_short}} GUI: kicksecure-qubes-gui
* {{q_project_name_short}} CLI kicksecure-qubes-cli
Derivatives such as [https://www.whonix.org {{Whonix}}] which are based on {{Kicksecure}}:
* See [https://www.whonix.org/wiki/Debian_Packages derivative ({{Whonix}}) specific documentation] instead of this wiki page.
Because derivatives of {{project_name_short}} install additional meta packages.
It is actually a good idea to safely run sudo apt autoremove
according to the following instructions on this wiki page to make sure extraneous packages which might no longer be recommended for default installation are removed.
= Re-install Meta Packages and Safely Run Autoremove =
{{Box|text=
'''1.''' [[Update]] the package lists.
{{CodeSelect|code=
sudo apt update
}}
'''2.''' Ensure a proper meta package is installed.
[[{{non_q_project_name_short}}|{{non_q_project_name_short}}]] Xfce:
* {{project_name_gateway_long}}: {{CodeSelect|code=
sudo apt install kicksecure-qubes-gui
}}
'''3.''' Auto remove packages.
{{CodeSelect|code=
sudo apt autoremove
}}
'''4.''' Reconfirm a proper meta package is still installed.
Repeat step two.
'''5.''' Done.
The procedure of safely running sudo apt autoremove
is complete.
Related: [[Factory Reset|{{project_name_short}} Factory Reset]]
}}
= Changed Configuration Files =
Be careful if a message like this appears.
Configuration file '/etc/apparmor.d/usr.bin.sdwdate' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** usr.bin.sdwdate (Y/I/N/O/D/Z) [default=N] ?For general advice, see: [[Operating_System_Software_and_Updates#Changed_Configuration_Files|Changed Configuration Files]]. = Package Version Check = If you need to check your package version, use
dpkg -l package-name
where package-name is the package you wish to check.
{{CodeSelect|code=
dpkg -l package-name
}}
Your output should look like this:
Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-=================================== ii grep 3.8-5 amd64 GNU grep, egrep and fgrep ii package-name 0.1 amd64 package-descriptionIf you wish to independently verify the version, you can either access the github of a package and check its changelog. See list of github repositories. * https://github.com/{{project_name_short}} * https://github.com/{{whonix}} Go to a github repository. Example github repository: https://github.com/{{project_name_short}}/sdwdate Click on the
debian
sub folder.
Click on the changelog
file. Example /debian/changelog
file:
https://github.com/{{project_name_short}}/sdwdate/blob/master/debian/changelog
On the very top of the changelog is the latest version number.
TODO: document how to view the version number using deb.kicksecure.com / deb.whonix.org
related: [[Reporting_Bugs#Package_Upgrade_Policy|Package Upgrade Policy]]
= Advanced Topics =
{{Anchor|Disadvantage}}
== Packages FAQ ==
'''Table:''' ''Meta-packages Frequently Asked Questionss''
{| class="wikitable"
|-
! scope="col"| '''Question'''
! scope="col"| '''Answer'''
|-
! scope="row"| What is the disadvantage of removing a meta package?
| The disadvantage is any changes in package dependencies will not be automatically processed by the system when it is [[Security_Guide#Updates|upgraded]].
For example the kicksecure-packages-recommended-gui
meta package depends
Depends:
field in debian/control
on package [https://github.com/{{project_name_short}}/tb-updater tb-updater]
. If the kicksecure-packages-recommended-gui
package is not installed, you would not notice if tb-updater
was [https://phabricator.whonix.org/T18 replaced] with package [https://packages.debian.org/torbrowser-launcher torbrowser-launcher
]. tb-updater
might become unmaintained, broken or even have unfixed security issues. {{project_name_short}} tries to [[Stay Tuned|keep users up-to-date]] if/when (security relevant) packages are deprecated. If that occurs, you could simply run sudo apt purge tb-updater
and consider installing what the {{project_name_short}} meta package recommends as a replacement.
See also: [[#Technical_Information|Technical Information]].
{{Anchor|Which ones are safe to remove?}}
|-
! scope="row"| Which meta packages are safe to remove?
| Use apt-cache to see the package description.
* Replace package-name
with the package you intend to install.
{{CodeSelect|code=
apt-cache package-name
}}
It will include either:
* Safe to remove, if you know what you are doing.
; or
* Do not remove.
Note the [[#Removal Instructions|Removal Instructions]] below! When that entry is understood, feel free to remove any [[#Non-Issues|desktop specific meta packages]].
|-
! scope="row"| Which packages do {{project_name_short}} meta packages install?
| Refer to the following files:
* [https://github.com/{{project_name_short}}/kicksecure-meta-packages/blob/master/debian/control debian/control
] in {{project_name_short}} [https://github.com/{{project_name_short}}/kicksecure-meta-packages kicksecure-meta-packages
] source code folder; and
* [https://github.com/{{project_name_short}}/kicksecure-meta-packages/blob/master/debian/control debian/control
] in {{project_name_short}} [https://github.com/{{project_name_short}}/kicksecure-meta-packages kicksecure-meta-packages
] source code folder.
Or use for example.
{{CodeSelect|code=
apt-cache show kicksecure-packages-recommended-gui
}}
{{Anchor|Which packages should never be removed?}}
|-
! scope="row"| Which meta packages should never be removed?
| Do not remove any packages which include the name dependencies
, unless the implications are fully understood.
TODO: document
|-
! scope="row"| How to uninstall qubes-core-agent-passwordless-root
without also uninstalling kicksecure-qubes-gui
or kicksecure-qubes-cli
?
| [https://forums.whonix.org/t/qubes-sudo-su-root-hardening-development-discussion/8561/4 Install] dummy-dependency
first, then drop qubes-core-agent-passwordless-root
:
{{CodeSelect|code=
sudo apt update
sudo apt install dummy-dependency
sudo apt purge qubes-core-agent-passwordless-root
}}
|-
! scope="row"| {{anchor_link|dummy-dependency}}
| TODO: document
* https://github.com/Kicksecure/helper-scripts/blob/master/usr/bin/dummy-dependency
* https://github.com/Kicksecure/helper-scripts/blob/master/man/dummy-dependency.8.ronn
|-
|}
== Removal Instructions ==
These instructions allow for safe removal of a package (in this example the sdwdate
package). This results in meta package removal without breaking the whole system when next time running sudo apt autoremove
.
{{Box|text=
'''1.''' Upgrade.
[[Operating_System_Software_and_Updates|Upgrade the system]].
'''2.''' Clean up.
If custom packages were installed and uninstalled or dependencies changed in the meanwhile, remove unneeded dependencies first.
{{CodeSelect|code=
sudo apt autoremove
}}
'''3.''' Uninstall.
As an example, consider how the [https://github.com/{{project_name_short}}/sdwdate {{Code2|sdwdate}}] package could be uninstalled.
{{CodeSelect|code=
sudo apt purge sdwdate
}}
A message will appear similar to this.
Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: faketime libfaketime Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: kicksecure-qubes-gui* sdwdate* kicksecure-shared-packages-recommended-cli* kicksecure-workstation-shared-packages-shared-meta* 0 upgraded, 0 newly installed, 4 to remove and 1 not upgraded. After this operation, 302 kB disk space will be freed. Do you want to continue? [Y/n]'''4.''' Keep packages installed by meta packages. Now, there is a small issue: * Next time the {{Code2|sudo apt autoremove}} command is run, all packages listed under "{{Code2|The following packages were automatically installed and are no longer required:}}" would also be uninstalled. (Such as {{Code2|[https://github.com/{{project_name_short}}/rads rads]}} and others.) * In order to keep the other packages which were installed such as by the {{Code2|kicksecure-packages-recommended-gui}} and the {{Code2|kicksecure-packages-recommended-cli}} meta packages, mark them as manually installed so they do not get removed. This can be conveniently achieved with {{Code2|aptitude}}. https://unix.stackexchange.com/questions/166590/what-is-the-apt-get-equvalent-of-aptitude-keep-all It is possible to safely mix {{Code2|apt-get}} and {{Code2|aptitude}}. Raphaël Hertzog, dpkg and Debian Developer, stated in 2011 that this is not a problem anymore:
First I want to make it clear that you can use both and mix them without problems. It used to be annoying when APT did not track which packages were automatically installed while aptitude did, but now that both packages share this list, there’s no reason to avoid switching back and forth.Source: [https://raphaelhertzog.com/2011/06/20/apt-get-aptitude-%E2%80%A6-pick-the-right-debian-package-manager-for-you/ apt-get, aptitude, … pick the right Debian package manager for you] {{CodeSelect|code= sudo aptitude keep-all }} '''5.''' Done. The procedure is complete. Be sure to understand the [[#Disadvantage|disadvantage]] of this approach. }} Alternatively, there might be a very crude workaround which is discussed in the following forum topic: [https://forums.whonix.org/t/issues-with-removal-of-specific-packages-by-users-builders/653/9 Issues with removal of specific packages by users / builders]. == Technical Information == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = This section provides technical information for interested readers and can be skipped. }} The underlying technical issues with meta packages are not caused by {{project_name_short}}, but instead have been inherited from Debian. Those are also described here: * [https://administratosphere.wordpress.com/2011/11/29/the-metapackage-problem-and-apt-get-autoremove/ The Metapackage Problem and apt autoremove] * [https://tanguy.ortolo.eu/blog/article8/uninstall-meta-package Uninstalling a single component of a meta-package] * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942303 Debian bug report: Weak-Depends - something in the middle between 'Recommends:' and 'Depends:'] * [https://lists.debian.org/debian-devel/2024/11/msg00018.html RFC: "Recommended bloat", and how to possibly fix it] * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086801 apt: autoremove fails to remove garbage packages with unrelated Suggests links] The Debian manual also provides further information about meta packages: * [https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-meta Best practices for meta-packages] The {{project_name_short}} build script installs all packages using
apt --no-install-recommends
.
Function pkg-install-maybe
in https://github.com/{{project_name_short}}/derivative-maker/blob/master/build-steps.d/3500_install-packages#L96C17.
The --no-install-recommends
option is being used to prevent installation of many additional packages that are unwanted. For example:
* kicksecure-packages-recommended-gui
(used to) Depends: gwenview
.
* gwenview Recommends: kamera
.
* Without using --no-install-recommends
, kamera
would also be installed and then pull its own Depends:
as well.
* kamera
[+ dependencies] would not be useful to have installed by default on {{project_name_workstation_short}} as it would cost unnecessary disk space. There are many more examples which could end up installing packages by default that are unrecommended for privacy reasons.
Since the --no-install-recommends
option is used, meta packages like kicksecure-packages-recommended-gui
must use the Depends:
field and cannot use the Recommends:
field. (Since no packages would be installed then.)
Even if {{project_name_short}} could and did use the Recommends:
field, new packages added to the Recommends:
field would not be installed when the meta package that Recommends:
them gets upgraded. This is because packages listed after the Recommends:
field only get installed during their initial sudo apt install package-name
installation.
Some readers might notice that despite this explanation, kicksecure-meta-packages
's debian/control
file uses the Recommends:
field anyway. This is not a contradiction because it may be useful for a later [[Dev/Installation_from_Repository|{{project_name_short}} installation from {{project_name_short}} repository]] use case.
Forum discussion: