Updating Linux Packages for C# Developers

How Linux Package Management Differs from Windows

[0:00 - 0:38] Tim opens by addressing a common stumbling block for developers coming from Windows. On Windows, each application typically manages its own updates. Visual Studio checks for updates independently from Edge, which updates separately from your printer drivers. There's no single system that tracks everything installed on your machine.

Linux takes a centralized approach. A package manager like apt (Advanced Package Tool) tracks every piece of software installed from the official repositories. When you run an update, apt queries the repositories for every installed package at once. Browser updates, library patches, SDK upgrades, and security fixes all arrive through the same pipeline.

For C# developers, this has real implications. Your .NET runtime, the OpenSSL libraries your HTTPS calls depend on, and the system-level dependencies your applications link against are all managed by this system. If you're getting started with C# on a non-Windows platform for the first time, knowing how the package manager works saves you from chasing down mysterious build failures later. A single apt upgrade keeps the entire stack aligned, something you'd need to coordinate across many separate updaters on Windows.

The GUI: Update Manager

[0:38 - 1:34] For developers who prefer a visual workflow, Tim walks through the Update Manager first. Linux Mint includes one that works similarly to Windows Update. A small icon in the lower-right corner of the taskbar opens it, and you'll see exactly what will be updated: Microsoft Edge, Firefox, curl, libssh, and more. Each entry displays the current version, the new version, and the download size.

All packages are selected by default, though you can uncheck items if you want to skip a particular update. That's useful if a specific version of a tool is required for your project and you don't want it changing mid-sprint.

You click "Install Updates," enter your password when prompted, and wait for the process to complete. The password prompt exists because modifying system packages is an administrative action, which we'll cover in the next section.

One thing the GUI does well: it classifies updates by risk level and is more conservative about changes that could affect system stability. For a developer new to Linux who just wants to keep their environment healthy without worrying about the details, the Update Manager is a solid default.

Understanding sudo

[1:34 - 1:51] Before moving to the terminal, Tim takes a moment to explain sudo, since it appears in every command line package operation. It's worth understanding what it does before you start typing. Most Windows user accounts are admin accounts by default, giving you full access to install, remove, and modify system software. Linux takes the opposite approach: your account runs with limited permissions, and you escalate to admin privileges only when needed.

Prefixing a command with sudo triggers a password prompt to verify your identity. Once authenticated, that command executes with root privileges, and then permissions drop back to normal. Package management (installing, removing, or updating software) is a system-level operation that could affect every application on the machine, so the explicit sudo prefix ensures you don't accidentally modify system packages when you intended to do something else.

If you've used Windows, think of it as similar to running Visual Studio as Administrator, except on Linux, you elevate individual commands rather than entire applications. It's a more targeted model.

The Command Line: apt update

[1:51 - 2:28] With sudo covered, Tim moves to the terminal. Working there gives you more granular control over the update process, and he walks through three commands in sequence. Understanding what each one does matters because, as he points out, the naming is deceptive.

The first command is:

sudo apt update

sudo apt update

A common assumption is that this command updates packages. It does not. apt update refreshes the package index, a local catalog of available software. Over time that catalog goes stale as maintainers release new versions, so running this command downloads the latest version from the repository servers. No software changes on your machine. It's purely an information-gathering step.

After running it, apt reports how many packages have newer versions available. You can inspect the full list before committing to any changes:

apt list --upgradeable

apt list --upgradeable

That gives you a line-by-line view of every package with a newer version available, including the current and new version numbers. If you're working with .NET on this machine, this is where you might spot SDK updates, runtime patches, or changes to libraries your application depends on. Understanding which .NET versions are in play on your machine helps you decide whether a particular upgrade is safe to apply or needs testing first.

The Command Line: apt upgrade

[3:01 - 3:40] Once the index is refreshed, Tim moves to the second command — the one that actually installs the newer versions:

sudo apt upgrade

sudo apt upgrade

Pay attention to the naming: update gets the latest information, upgrade is what changes the packages. That two-step split is intentional. It separates the "check what's available" step from the "apply changes" step, giving you time to review, research, or back up before anything moves.

Under the hood, upgrade follows strict rules about what it will and won't do. It downloads and installs newer versions of packages already on your system, but will never remove an existing package or install a new one that wasn't previously present. When a newer version needs a dependency that isn't installed, upgrade holds that package back rather than pulling in the new dependency automatically.

The upside is predictability. Keeping your .NET stack up to date matters, but so does doing it in a controlled way. The system prompts you with a summary of what will change and asks you to confirm before proceeding, so nothing happens without your explicit permission.

The Command Line: apt full-upgrade

[3:40 - 4:19] With the safe updates applied, Tim introduces the third command to handle everything upgrade deliberately held back:

sudo apt full-upgrade

sudo apt full-upgrade

full-upgrade handles the cases that upgrade deliberately avoids. If a package update requires installing new dependencies or removing conflicting packages, full-upgrade will do it. Kernel upgrades, major system library changes, and OS-level patches are applied here.

Running this as a separate step gives you a layered approach. If something goes wrong during complex dependency resolution, you've already applied the straightforward updates and only need to troubleshoot the more involved ones.

For teams managing a build pipeline that compiles C# applications on Linux, this staged workflow is especially relevant. In an automated CI/CD environment, you might choose to run only apt upgrade for stability, reserving full-upgrade for scheduled maintenance windows where you can verify that everything still compiles and passes after deeper system changes.

Why the Package Counts Differ

[2:28 - 3:01] Something that regularly trips people up: the Update Manager might show 23 updates, while the command line reports 79 packages. These aren't different sets of updates; it's the same system counted differently.

The GUI groups related packages into logical units. A single "Firefox update" in the Update Manager might actually consist of the Firefox binary, its localization pack, shared libraries it depends on, and a configuration package, each tracked as a separate package by apt. So what the Update Manager presents as one update, apt lists as four or five individual package upgrades.

Once you know this, the discrepancy stops being puzzling. Someone might say "I had 100 packages to upgrade" for the same set of changes your Update Manager shows as 30 updates.

Flatpak: A Separate Package Manager

[5:56 - 6:41] There's a catch that's easy to miss: Linux can have multiple package managers installed, and apt only knows about packages it manages. Flatpak is one such alternative; it's a sandbox-based system that packages applications with their own dependencies, isolating them from the rest of the system.

If you've installed software through Flatpak, running apt upgrade won't touch those applications. You need to update them separately:

flatpak list
flatpak update

flatpak list
flatpak update

The flatpak list command shows everything installed via Flatpak, and flatpak update brings those packages to their latest versions. It's good practice to check regularly, especially if you've installed IDEs, database tools, or communication apps through it.

On Linux, software can arrive through apt, Flatpak, Snap, or even manual installations. Each has its own update mechanism, so a thorough update routine should account for all of them. If you're used to every application shipping its own updater, the key difference here is that you need to know which package manager owns which piece of software, and run the right update command for each.

Which Method Should You Use?

[4:19 - 5:32] Tim's take is that both approaches are valid, and the right choice comes down to your workflow. If you're more comfortable with a visual interface, the Update Manager handles the same updates apt does through a point-and-click interface. You don't need to memorize commands or worry about running steps in the wrong order. That said, there's a good reason to get comfortable with the command line: automation. You can create a simple shell script that runs the full update sequence and schedule it to execute weekly using cron. A three-line script that keeps your system current without you having to think about it is the kind of small investment that compounds over time.

Beyond automation, the command line lets you selectively apply certain upgrade levels depending on the context, or pipe output into other tools for analysis. These options aren't available through the GUI.

Auditing Your Installed Packages

[7:16 - 7:54] There's also a useful side effect of the update process: reviewing your update list doubles as an audit of what's installed on your system. When you see a package in the update queue, it's worth asking whether you still need it.

You might see Firefox in the update list when you primarily use Edge, or vice versa. Keeping two browsers installed for cross-browser testing of web applications makes sense, but the broader principle is that the update list exposes the full footprint of your development environment. Stale tools from a previous project, development libraries that were pulled in as dependencies and never cleaned up, packages you forgot you installed six months ago: they all show up here.

That kind of housekeeping pays off more than you'd expect. A clean development environment is easier to replicate across team members, simpler to containerize, and less likely to produce "works on my machine" bugs. If your Linux box has packages installed that your Dockerfile doesn't include, you may be relying on something that won't exist in production. Getting familiar with deploying C# applications to Docker makes this connection between your local packages and your production environment much more concrete.

Conclusion

[7:54 - 8:25] As Tim demonstrates, the entire process — whether through the Update Manager or the command line — takes a few minutes at most and protects you from accumulating technical debt at the OS level. Making it a weekly habit rather than an occasional chore keeps your development tools, runtime dependencies, and system libraries aligned, and that alignment is what makes cross-platform C# development reliable rather than frustrating.

For the full step-by-step walkthrough, check out Tim Corey's video on his YouTube channel.