I am working with very constrained embedded hardware where I cannot afford to have many packages installed; however, I need Python3.10, which I built from source (my apt only offers Python3.7).

In doing so, I installed build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev wget libbz2-dev, and tens of additional dependencies for those packages. As a result, my OS is too large to load on the embedded hardware.

Once Python3.10 is installed, is it okay to apt-get purge the above packages and their dependencies? I have tested very basic Python programs after doing so and things seem fine, but could this cause trouble down the road?

  • Please refer askubuntu.com/help/on-topic, Ubuntu and official flavors of Ubuntu (ubuntu.com/download/flavours) are on-topic on this site. The on-topic link provides alternate SE sites for non-Ubuntu OSes. You've mentioned using a python3 version from an EOL release, and probably are using Debian given you tagged the question about a Debian/Ubuntu workflow issue where it's not
    – guiverc
    Commented May 14 at 22:31
  • 3
    Yes, it is OK to remove the dependencies used to build python3.10. However, since you are short on storage, you can install Ubuntu Server (which comes with a minimal CLI and a lot less default packages than regular Ubuntu), and install Miniconda to set up a minimal python 3.10 environment. Also note that removing the default python version may lead to serious errors including APT not working anymore. Commented May 15 at 2:45
  • Thanks! I've been using make altinstall so no worries about removing the default Python3. Commented May 16 at 17:51

1 Answer 1


You can subdivide build dependencies into several groups:

  • tools necessary to execute the build, like make, gcc and a lot of the other dependencies included in build-essential
  • development libraries necessary to build and link binaries like what is in zlib1g-dev and the rest of your *-dev list
  • runtime libraries (which you didn't list any of) which are typically dependencies to the *-dev packages.
  • external support executables as well as data files used at runtime

The first two you can remove after the build is complete. The third list are typically shared libraries, but there may be support files in that too. This is a much harder list to determine.

You might be able to remove the dev libraries and then pick through what autoremove wants to remove to figure out how many of those are critical shared libraries.

Or you can pick through your built target and run ldd on the executables and libraries and figure out what the necessary packages are for the found shared libraries. Note that not all of these will be found with in the above suggested autoremove list! Also, this won't find libraries that are detected at runtime and dynamically loaded rather than actually linked at compile time.

Picking out packages with needed support files might be even harder, as without careful analysis. I'd hate to remove them only to find things that crashed without them, assuming you manage to hit that code path while you are testing rather than in production!

In short, there's no easy clean answer. It takes careful analysis, good knowledge of all your applications, and maybe still some trial and error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .