Debian_Packages.mw

{{Header}}
{{title|title=
Debian Packages
}}
{{#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
}}
{{release_mininav}}
[[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 <code>sudo apt autoremove</code> so long as the specific {{project_name_short}} machine <code>meta package</code> is kept for the {{non_q_project_name_short}} or {{q_project_name_short}} platform. In other words, these packages should <u>not</u> be in the list of autoremoved packages.

== [[About|{{project_name_short}}]] ==

{{Tab
|type=controller
|linkid=oschoice
|content=

{{Tab
|title= === {{project_name_workstation_long}} LXQt ===
|image=[[File:Kicksecure-logo-rectangle.svg|50px]]
|addToClass=info-box
|content=

* 17: <code>kicksecure-xfce</code>
* 18: <code>kicksecure-vm-gui-lxqt</code> for VMs, <code>kicksecure-baremetal-gui-lxqt</code> for physical hardware

}} <!-- close tab: Kicksecure LXQt -->

{{Tab
|title= === {{project_name_workstation_short}} CLI ===
|image=[[File:Utilities-terminal.png|25px]]
|addToClass=info-box
|content=

* 17: <code>kicksecure-cli</code>
* 18: <code>kicksecure-baremetal-cli</code> for physical hardware

}} <!-- close tab: Kicksecure Workstation CLI -->

{{Tab
|title= === {{project_name_workstation_short}} Server ===
|image=[[File:Web_server.png|25px]]
|addToClass=info-box
|content=

* 17: None.
* 18: <code>kicksecure-vm-server</code> for virtual servers (VPS) (VMs)
* 18: <code>kicksecure-baremetal-server</code> for physical hardware

}} <!-- close tab: Kicksecure Server CLI -->

}} <!-- close Controller: Kicksecure Workstation LXQt&CLI -->

== [[Qubes|{{q_project_name_long}}]] ==

{{Tab
|type=controller
|linkid=oschoice
|content=

{{Tab
|title= === {{q_project_name_short}} GUI ===
|image=[[File:Qubes-logo-icon.png|25px]]
|addToClass=info-box
|content=

* 17: <code>kicksecure-qubes-gui</code>
* 18: <code>kicksecure-qubes-gui-lxqt</code>

}} <!-- close tab: Qubes-Kicksecure GUI -->

{{Tab
|title= === {{q_project_name_short}} CLI ===
|image=[[File:Utilities-terminal.png|25px]]
|addToClass=info-box
|content=

* 17: <code>kicksecure-qubes-cli</code>
* 18: <code>kicksecure-qubes-cli</code>

}} <!-- close tab: Qubes-Kicksecure CLI -->
}} <!-- close Controller: Qubes-Kicksecure GUI&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. <ref>
Because derivatives of {{project_name_short}} install additional meta packages.
</ref>

It is actually a good idea to safely run <code>sudo apt autoremove</code> 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=
{{IconSet|h1|1}} [[Update]] the package lists.

{{CodeSelect|code=
sudo apt update
}}

{{IconSet|h1|2}} Ensure a proper meta package is installed. <ref>
The apt install commands are not strictly required if these packages are already installed. However, the simplest approach is to run these commands to follow the documentation as is.

* Either the packages are already installed: then the command does no harm.  
* Or the packages are not installed: then these commands are necessary.

The alternative would require more extensive documentation, with a step like "check if this package is installed" followed by "only if missing, install it", but that would make the documentation unnecessarily bloated.
</ref>

Platform specific. Select your platform.

{{Tab
|type=controller
|content=
{{Tab
|title= == [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]] LXQt ==
|image=[[File:Kicksecure-logo-rectangle.svg|50px]]
|addToClass=info-box
|active=true
|content=

For VMs:

{{CodeSelect|code=
sudo apt install kicksecure-vm-gui-lxqt
}}

For physical hardware:

{{CodeSelect|code=
sudo apt install kicksecure-baremetal-gui-lxqt
}}

}} <!-- close tab: kicksecure-lxqt -->

{{Tab
|title= == [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]] CLI ==
|image=[[File:Utilities-terminal.png|25px]]
|addToClass=info-box
|content=

For VMs:

{{CodeSelect|code=
sudo apt install kicksecure-vm-server
}}

For physical hardware:

{{CodeSelect|code=
sudo apt install kicksecure-baremetal-server
}}

}} <!-- close tab: kicksecure-cli -->

{{Tab
|title= == [[Qubes|{{q_project_name_short}}]] ==
|image=[[File:Qubes-logo-icon.png|25px]]
|addToClass=info-box
|content=

{{CodeSelect|code=
sudo apt install kicksecure-qubes-gui-lxqt
}}

}} <!-- close tab: Qubes-Kicksecure-gui -->
}} <!-- close Controller: kicksecure-lxqt,cli,qubes -->

{{IconSet|h1|3}} Autoremove packages.

{{CodeSelect|code=
sudo apt autoremove
}}

{{IconSet|h1|4}} Reconfirm a proper meta package is still installed.

Repeat step two.

{{IconSet|h1|5}} Done.

The procedure of safely running <code>sudo apt autoremove</code> is complete.

Related: [[Factory Reset|{{project_name_short}} Factory Reset]]
}}

https://forums.whonix.org/t/should-apt-get-autoremove-be-automated-during-release-upgrade-and-or-upgrade-nonroot/22340

= Changed Configuration Files =
Be careful if a message like this appears.

<pre>
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] ?
</pre>

For general advice, see: [[Operating_System_Software_and_Updates#Changed_Configuration_Files|Changed Configuration Files]].

Related:

* <code>ucf</code> ([https://packages.debian.org/ucf package]) ([https://manpages.debian.org/ucf man page])

= Package Version Check =
If you need to check your package version, use <code>dpkg -l package-name</code> where package-name is the package you wish to check.

{{CodeSelect|code=
dpkg -l package-name
}}

Your output should look like this:

<pre>
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-description
</pre>

If 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. <u>Example</u> GitHub repository:

<u>Note:</u> Replace the example repository with the actual repository you wish to version check.

{{Github_link|
https://github.com/Kicksecure/sdwdate
}}

Click on the <code>debian</code> sub folder.

Click on the <code>changelog</code> file. Example <code>/debian/changelog</code> file:

{{Github_link|
https://github.com/Kicksecure/sdwdate/blob/master/debian/changelog
}}

On the very top of the changelog is the latest version number.

<u>Note:</u> Source code version might be ahead of repository version.

Related: [[Reporting_Bugs#Package_Upgrade_Policy|Package Upgrade Policy]]

== Repository Version Check ==
How to view the version number using Kicksecure repository <code>deb.kicksecure.com</code> (or for Debian packages or if using a derivative such as Whonix)?

Since a convenient web interface such as packages.debian.org hasn't been implemented yet for Kicksecure (and Whonix) <ref>
[https://forums.whonix.org/t/packages-debian-org-apt-package-repository-web-interface-for-deb-whonix-org/10937 packages.debian.org APT package repository web interface for deb.kicksecure.com / deb.whonix.org]
</ref>, this is a bit difficult.

{{IconSet|h1|1}} Go to https://deb.kicksecure.com

{{IconSet|h1|2}} Click on "<code>dists</code>" <ref>
https://deb.kicksecure.com/dists/
</ref>

{{IconSet|h1|3}} Click on the release codename you're interested in such as "<code>{{Stable project version based on Debian codename}}</code>". <ref>
https://deb.kicksecure.com/dists/bookworm/
</ref>

{{IconSet|h1|4}} Click on the component. Most likely "<code>main</code>". <ref>
https://deb.kicksecure.com/dists/bookworm/main/
</ref>

{{IconSet|h1|5}} Click on the architecture. Most likely "<code>binary-amd64</code>". <ref>
https://deb.kicksecure.com/dists/bookworm/main/binary-amd64/
</ref>

{{IconSet|h1|6}} Click on the "<code>Packages</code>" file. <ref>
https://deb.kicksecure.com/dists/bookworm/main/binary-amd64/Packages
</ref>

{{IconSet|h1|7}} Read the first 100 lines of that file to get an idea what it does.

{{IconSet|h1|8}} Search the file for the package you're interested in such as for example: {{CodeSelect|inline=true|code=Package: sdwdate}}

{{IconSet|h1|9}} Result might be as follows.

<pre>
Package: sdwdate
Version: 3:25.8-1
</pre>

Interpretation:

* The <code>3:</code> can be ignored. That is the version epoch.
* The <code>-1</code> can also be ignored. That is the Debian package revision number which is not used much yet.
* Ignoring these two parts, version number at time of writing was <code>25.8</code>.

= Advanced Topics =
{{Anchor|Disadvantage}}

== Packages FAQ ==

{| class="wikitable"
|+ ''Meta-packages Frequently Asked Questions''
|-

! '''Question'''
! '''Answer'''
|-

! 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 [[update|updated]].

For example the <code>dist-nonqubes-cli</code> meta package depends <ref>
<code>Depends:</code> field in <code>debian/control</code>
</ref> on the package [https://github.com/{{project_name_short}}/grub-live <code>grub-live-dracut</code>]. If the <code>dist-nonqubes-cli</code> package is not installed, you would not notice if <code>grub-live-dracut</code> was replaced with some other package. <code>grub-live-dracut</code> 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 <code>sudo apt purge tb-updater</code> 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?}}
|-

! Which meta packages are safe to remove?
| Previously, in {{project_name_short}} 17, some meta packages were marked as "Safe to remove", while others were marked "Do not remove". In {{project_name_short}} 18, this is no longer the case; meta packages are not designed to be removed. If you need to remove a package depended on by a {{project_name_short}} meta package, use [[#dummy-dependency|dummy-dependency]] to remove that specific package.
|-

! Which packages do {{project_name_short}} meta packages install?
| Refer to the following file:

* {{Github_link|
https://github.com/Kicksecure/kicksecure-meta-packages/blob/master/debian/control
}} in {{project_name_short}} [https://github.com/{{project_name_short}}/kicksecure-meta-packages <code>kicksecure-meta-packages</code>] source code folder.

Or use for example.

{{CodeSelect|code=
apt-cache show kicksecure-vm-gui-lxqt
}}
{{Anchor|Which packages should never be removed?}}
|-

! Which meta packages should never be removed?
| Do not remove any {{project_name_short}}-specific meta packages. If you need to remove a package depended on by a meta package, use [[#dummy-dependency|dummy-dependency]] to remove that specific package.
|-

! How to uninstall <code>qubes-core-agent-passwordless-root</code> without also uninstalling <code>kicksecure-qubes-gui</code> or <code>kicksecure-qubes-cli</code>?
|
{{CodeSelect|code=
dummy-dependency --purge qubes-core-agent-passwordless-root
}}
|-

|}

== dummy-dependency ==
<code>dummy-dependency</code> <ref>
{{Github_link|
https://github.com/Kicksecure/helper-scripts/blob/master/usr/bin/dummy-dependency
}}
</ref> ({{Github_link|
https://github.com/Kicksecure/helper-scripts/blob/master/man/dummy-dependency.8.ronn
}}) can be used to install a dummy dependency package in place of a real dependency package. This allows:

{{IconSet|h2|A}} the uninstallation of packages that are normally not uninstallable, without removing a (meta) package that depends on the original package. And/or;

{{IconSet|h2|B}} avoiding the installation of dependency packages that are considered problematic, such as [https://packages.debian.org/{{Stable_project_version_based_on_Debian codename}}/geoclue-2.0 GeoClue] (due to [https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/177 privacy concerns associated with GeoClue]), which might be pulled in as a dependency.

== Removal Instructions ==

{{IconSet|h1|1}} {{sysmaint_notice}}

{{IconSet|h1|2}} '''Syntax.'''

<u>Notes:</u>

* Replace <code>package-name</code> with the actual package that you want to remove.
* Optional: <code>--purge</code>. Same as <code>apt-get purge</code>.
* Optional: <code>--yes</code>. Does not ask for confirmation.

{{CodeSelect|code=
sudo dummy-dependency --yes --purge package-name
}}

{{IconSet|h1|3}} '''Example.'''

<u>Notes:</u>

* Replace <code>user-sysmaint-split</code> with the actual package that you want to remove.
* Optional: <code>--purge</code>. Same as <code>apt-get purge</code>.
* Optional: <code>--yes</code>. Does not ask for confirmation.

{{CodeSelect|code=
sudo dummy-dependency --yes --purge user-sysmaint-split
}}

{{IconSet|h1|4}} '''Done.'''

The package has been completed.

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].

= Installing real versions of dummy packages =
Sometimes, attempting to install a particular application will attempt to remove critical metapackages, and a "dummy-dependency" package. For instance, if you run <code>sudo apt install postfix</code> (to install the Postfix mail transport agent) you will see something similar to this:

<pre>
Installing:
  postfix

Installing dependencies:
  libnsl2  libtlsrpt0  ssl-cert

Suggested packages:
  ...

REMOVING:
  dist-general-cli  dummy-dependency-mta  kicksecure-vm-gui-lxqt

...
</pre>

This is because the package has been replaced in {{project_name_short}} by a dummy-dependency package (in this case, <code>dummy-dependency-mta</code>). This is usually done to prevent certain applications from being installed automatically. The <code>dummy-dependency-mta</code> package is depended on by <code>dist-general-cli</code>, so attempting to install a real mail transport agent like Postfix will attempt to uninstall <code>dist-general-cli</code>.

The best way to work around this is to replace the <code>dummy-dependency-*</code> package with another dummy-dependency package. This will unblock the application replaced by the original <code>dummy-dependency-*</code> package. To do this:

{{Box|text=
{{IconSet|h1|1}} {{sysmaint_notice}}

{{IconSet|h1|2}} Run.

(Replace <code>dummy-dependency-package</code> with the name of the package you want to replace, such as <code>dummy-dependency-mta</code>.)

{{CodeSelect|code=
sudo dummy-dependency --yes --purge dummy-dependency-package
}}

{{IconSet|h1|3}} Done.

The process of removing a <code>dummy-dependency-*</code> package is complete.
}}

The following dummy-dependency packages exist to replace other packages by default. These can all be removed using the instructions above.

* <code>dummy-dependency-mta</code> (replaces anything that provides <code>default-mta</code> and/or <code>mail-transport-agent</code>, such as <code>postfix</code>, <code>exim4</code>, etc.)
* <code>dummy-dependency-sway</code> (replaces <code>sway</code>)
* <code>dummy-dependency-lxqt-policykit</code> (replaces <code>lxqt-policykit</code>)

== 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 <code>apt --no-install-recommends</code>. <ref>
Function <code>pkg-install</code> in {{Github_link|
https://github.com/Kicksecure/derivative-maker/blob/master/build-steps.d/3500_install-packages#L94.
}}
</ref> The <code>--no-install-recommends</code> option is being used to prevent installation of many additional packages that are unwanted. For example:
* <code>kicksecure-packages-recommended-gui</code> (only present in {{project_name_short}} 17 and earlier) used to <code>Depends: gwenview</code>.
* gwenview <code>Recommends: kamera</code>.
* Without using <code>--no-install-recommends</code>, <code>kamera</code> would also be installed and then pull its own <code>Depends:</code> as well.
* <code>kamera</code> [+ 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 <code>--no-install-recommends</code> option is used, meta packages like <code>kicksecure-packages-recommended-gui</code> must use the <code>Depends:</code> field and cannot use the <code>Recommends:</code> field. (Since no packages would be installed then.)

Even if {{project_name_short}} could and did use the <code>Recommends:</code> field, new packages added to the <code>Recommends:</code> field would not be installed when the meta package that <code>Recommends:</code> them gets upgraded. This is because packages listed after the <code>Recommends:</code> field only get installed during their initial <code>sudo apt install package-name</code> installation.

<!-- Some readers might notice that despite this explanation, <code>kicksecure-meta-packages</code>'s <code>debian/control</code> file uses the <code>Recommends:</code> field anyway. This is not a contradiction because it may be useful for a later [[Debian|{{project_name_short}} distribution morphing installation method]] use case.

Commented out because this no longer seems to be the case; we're now using "Depends:" everywhere. -->

Forum discussion:<br />
[https://forums.whonix.org/t/issues-with-removal-of-specific-packages-by-users-builders Issues with removal of specific packages by users / builders]

= See Also =
* [[Configuration_Files#Configuration_Drop-In_Folders|Configuration Drop-In Folders]]
* [[Configuration_Files#Reset_Configuration_Files_to_Vendor_Default|Reset Configuration Files to Vendor Default]]
* [[Factory Reset|{{project_name_short}} Factory Reset]]
* [[Packages for Debian Hosts]]
* [[Project-APT-Repository|{{project_name_short}} APT Repository]]
* [[Dev/Build Documentation‏‎|Building and Update {{project_name_short}} from Source Code]]

= Footnotes =
<references />

{{Footer}}

[[Category:Documentation]]