Removing packages from core

[Member Keeely]

I would like to remove a bunch of stuff from core, for instance anything audio or multimedia-related. I was going to do that prior to running the cli-installer, however I get all kinds of errors from doing this, and it says I need –allow-remove-essential. I’m not explicitly removing anything I consider essential, but I guess some libs are dependencies of packages that are essential.

I wondered if anyone has figured out a way to say “remove all packages in this list except the ones that you can’t remove without removing essential”, instead of the steam-roller of applying –allow-remove-essential, or if anyone created a list of packages that are safe to remove and put it somewhere?

[Member Xecure]

Helpful

Up

0

::

apt-mark showmanual
Will show you the individual packages installed “manually”, and not their dependencies. Start removing the ones you don’t want from that list.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Keeely]

Helpful

Up

0

::

Thanks. With a small amount of experimentation, this provided an ‘easy win’:

apt remove -y alsa-tools alsa-utils mpg123 ffmpeg firmware-* irssi-* reiser*
apt autoremove -y

[Anonymous]

Helpful

Up

0

::

> I guess some libs are dependencies of packages that are essential

https://www.debian.org/doc/debian-policy/ch-binary.html

The [debian] base system is a minimum subset of the Debian system that is installed before everything else on a new system. Only very few packages are allowed to form part of the base system, in order to keep the required disk usage very small.

The base system consists of all those packages with priority required or important. Many of them will be tagged essential (see below).

[Section] 3.8. Essential packages

Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the “Unpacked” state. Packages are [by the person(s) serving the role of debian Package Maintainer] tagged essential for a system using the Essential control field. The format of the Essential control field is described in Essential.

Since these packages cannot be easily removed (one has to specify an extra force option to dpkg to do so), this flag must not be used unless absolutely necessary. A shared library package must not be tagged essential; dependencies will prevent its premature removal, and we need to be able to remove it when it has been superceded.

Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured. If the package cannot satisfy this requirement it must not be tagged as essential, and any packages depending on this package must instead have explicit dependency fields as appropriate.

Maintainers should take great care in adding any programs, interfaces, or functionality to essential packages. Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. Any capability added to an essential package therefore creates an obligation to support that capability as part of the Essential set in perpetuity.

You must not tag any packages essential before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached.

https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages. The Replaces control field has these two distinct purposes.

To override//workaround hard-imposed dependencies when paring down the core packages, you can create a bogus package whose debian/control file specifies
Replaces: somepackage, anotherpackage, bigfatmonsterpkg…
( and/or Provides: blahblah, anotherblah… )
After installing the bogus package, the package management system would not object to purging the “replaced” packages. This approach begs considerable forethought because, yes, it introduces the risk of future breakage.

Along with “Replaces:”, you can additionally specify
Breaks: somepackage, anotherpackage, bigfatmonsterpkg
Conflicts: somepackage, anotherpackage, bigfatmonsterpkg

Upon installation of your bogus package, the package management system would automatically purge those declared-as-replaced packages (which your package is bogusly “replacing”)

[Author]

Posts