Aktualizowanie pakietów Linux dla deweloperów C#

Jak zarządzanie pakietami w Linuxie różni się od Windows

[0:00 - 0:38] Tim zaczyna od omówienia powszechnego problemu dla deweloperów przechodzących z Windows. Na Windows każda aplikacja zazwyczaj zarządza swoimi aktualizacjami. Visual Studio sprawdza aktualizacje niezależnie od Edge, który aktualizuje się osobno od sterowników drukarki. Nie ma pojedynczego systemu, który śledzi wszystko zainstalowane na twoim komputerze.

Linux przyjmuje podejście scentralizowane. Menedżer pakietów, taki jak apt (Advanced Package Tool), śledzi każdy kawałek oprogramowania zainstalowany z oficjalnych repozytoriów. Kiedy uruchamiasz aktualizację, apt zapytuje repozytoria o każdy zainstalowany pakiet jednocześnie. Aktualizacje przeglądarek, poprawki bibliotek, uaktualnienia SDK i poprawki zabezpieczeń docierają przez ten sam kanał.

Dla deweloperów C# to ma prawdziwe znaczenie. Twoja platforma .NET, biblioteki OpenSSL, na których opierają się twoje wywołania HTTPS, oraz zależności na poziomie systemu, do których łączą się twoje aplikacje, są zarządzane przez ten system. Jeśli zaczynasz przygodę z C# na platformie innej niż Windows po raz pierwszy, znajomość tego, jak działa menedżer pakietów, oszczędza Ci długiego pościgu za tajemniczymi błędami w budowie. Jedna apt upgrade utrzymuje całą warstwę spójną, co zwykle trzeba by było skoordynować wśród wielu oddzielnych aktualizatorów na Windows.

GUI: Menedżer Aktualizacji

[0:38 - 1:34] Dla deweloperów, którzy wolą wizualny przepływ pracy, Tim najpierw przechodzi przez Menedżera Aktualizacji. Linux Mint zawiera jeden, który działa podobnie do Windows Update. Mała ikona w prawym dolnym rogu paska zadań otwiera go i widzisz dokładnie, co zostanie zaktualizowane: Microsoft Edge, Firefox, curl, libssh i więcej. Każda pozycja pokazuje obecną wersję, nową wersję i rozmiar pliku do pobrania.

Wszystkie pakiety są domyślnie zaznaczone, ale można odznaczyć pozycje, jeśli chcesz pominąć określoną aktualizację. To jest przydatne, jeśli do projektu wymagańa jest konkretna wersja narzędzia i nie chcesz, aby zmieniała się w trakcie sprintu.

Klikasz "Zainstaluj aktualizacje", wpisujesz hasło, gdy jesteś o to poproszony, i czekasz, aż proces się zakończy. Monit o hasło istnieje, ponieważ modyfikacja pakietów systemówych jest działaniem administracyjnym, co omówimy w następnej sekcji.

Jedna rzecz, którą GUI robi dobrze: klasyfikuje aktualizacje według poziomu ryzyka i jest bardziej konserwatywna wobec zmian, które mogą wpływać na stabilność systemu. Dla dewelopera nowego w Linuxie, który po prostu chce utrzymać swoje środowisko w dobrym stanie bez martwienia się o szczegóły, Menedżer Aktualizacji jest solidnym ustawieniem domyślnym.

Zrozumienie sudo

[1:34 - 1:51] Zanim przejdziemy do terminala, Tim poświęci chwilę, aby wyjaśnić sudo, ponieważ pojawia się w każdym poleceniu linii komend dotyczącej pakietów. Warto zrozumieć, co to robi, zanim zaczniesz pisać. Większość kont użytkowników Windows jest domyślnie kontami administratorów, dając Ci pełny dostęp do instalowania, usuwania i modyfikowania oprogramowania systemówego. Linux przyjmuje przeciwne podejście: Twoje konto działa z ograniczonymi uprawnieniami, a do przywilejów administratora dochodzisz tylko wtedy, gdy to konieczne.

Prefiksując polecenie sudo wywołuje monit o hasło, aby zweryfikować Twoją tożsamość. Po autoryzacji to polecenie jest wykonywane z uprawnieniami administratora (roota), a następnie uprawnienia wracają do normy. Zarządzanie pakietami (instalowanie, usuwanie lub aktualizacja oprogramowania) to operacja na poziomie systemu, która może wpływać na każdą aplikację na komputerze, więc jawne sudo zapewnia, że nie zmodyfikujesz przypadkiem pakietów systemówych, gdy chcesz zrobić coś innego.

Jeśli korzystałeś z Windows, pomyśl o tym jako o podobnym do uruchamiania Visual Studio jako Administrator, z tym że na Linuxie unosisz indywidualne polecenia, a nie całe aplikacje. Jest to bardziej ukierunkowany model.

Linia poleceń: apt update

[1:51 - 2:28] Po omówieniu sudo Tim przechodzi do terminala. Praca tam daje Ci bardziej szczegółową kontrolę nad procesem aktualizacji i omawia trzy polecenia w kolejności. Zrozumienie, co każde z nich robi, ma znaczenie, ponieważ, jak zauważa, nazewnictwo jest mylące.

Pierwsze polecenie to:

sudo apt update

sudo apt update

Powszechnym założeniem jest, że to polecenie aktualizuje pakiety. Nie robi tego. apt update odświeża indeks pakietów, lokalny katalog dostępnego oprogramowania. Z czasem ten katalog się starzeje, gdy utrzymujący wypuszczają nowe wersje, więc uruchomienie tego polecenia pobiera najnowszą wersję z serwerów repozytoriów. Żadne zmiany oprogramowania na Twoim komputerze. Jest to czysto krok zbierania informacji.

Po jego uruchomieniu apt informuje, ile pakietów ma dostępne nowsze wersje. Możesz przejrzeć pełną listę, zanim zdecydujesz się na jakiekolwiek zmiany:

apt list --upgradeable

apt list --upgradeable

To daje Ci widok linia po linii każdego pakietu z nowszą dostępną wersją, w tym aktualne i nowe numery wersji. Jeśli pracujesz z .NET na tym komputerze, tu możesz dostrzec aktualizacje SDK, poprawki runtime lub zmiany w bibliotekach, od których zależy Twoja aplikacja. Zrozumienie które wersje .NET są używane na Twoim komputerze pomaga Ci zdecydować, czy konkretną aktualizację można bezpiecznie zastosować, czy wymaga najpierw przetestowania.

Linia poleceń: apt upgrade

[3:01 - 3:40] Gdy indeks zostanie odświeżony, Tim przechodzi do drugiego polecenia — tego, które faktycznie instaluje nowsze wersje:

sudo apt upgrade

sudo apt upgrade

Zwróć uwagę na nazewnictwo: update pobiera najnowsze informacje, upgrade to to, co zmienia pakiety. Ten podział na dwa kroki jest zamierzony. Oddziela krok "sprawdź, co jest dostępne" od kroku "zastosuj zmiany", dając Ci czas na przegląd, zbadanie lub wykonanie kopii zapasowej przed podjęciem jakichkolwiek działań.

Pod "maską" upgrade wykonuje ścisłe reguły, co zrobi, a czego nie. Pobiera i instaluje nowsze wersje pakietów już na Twoim systemie, ale nigdy nie usunie istniejącego pakietu ani nie zainstaluje nowego, który wcześniej nie był obecny. Gdy nowsza wersja wymaga zależności, która nie jest zainstalowana, upgrade wstrzymuje ten pakiet, zamiast automatycznie pobierać nową zależność.

Zaletą jest przewidywalność. Utrzymywanie Twojej warstwy .NET na bieżąco ma znaczenie, ale równie ważne jest robienie tego w sposób kontrolowany. System przedstawia Ci podsumowanie tego, co się zmieni i prosi o potwierdzenie przed przystąpieniem do działania, aby nic się nie działo bez Twojej wyraźnej zgody.

Linia poleceń: apt full-upgrade

[3:40 - 4:19] Z bezpiecznymi aktualizacjami zastosowanymi, Tim przedstawia trzecie polecenie do obsługi wszystkiego, co upgrade celowo zatrzymało:

sudo apt full-upgrade

sudo apt full-upgrade

full-upgrade obsługuje przypadki, które upgrade celowo unika. Jeśli aktualizacja pakietu wymaga zainstalowania nowych zależności lub usunięcia konfliktujących pakietów, full-upgrade to zrobi. Aktualizacje kernela, główne zmiany bibliotek systemówych i poprawki na poziomie OS są stosowane tutaj.

Uruchamianie tego jako osobnego kroku daje podejście warstwowe. Jeśli coś pójdzie nie tak podczas skomplikówanego rozwiązywania zależności, już zastosowałeś proste aktualizacje i musisz jedynie rozwiązać bardziej złożone.

Dla zespołów zarządzających pipeline'em, który kompiluje aplikacje C# na Linuxie, taki podejście jest szczególnie istotne. W zautomatyzowanym środowisku CI/CD możesz zdecydować, aby uruchamiać tylko apt upgrade dla stabilności, rezerwując full-upgrade na zaplanowane okna konserwacyjne, gdzie możesz zweryfikować, że wszystko wciąż się kompiluje i działa poprawnie po głębszych zmianach systemówych.

Dłączego liczba pakietów różni się

[2:28 - 3:01] Coś, co regularnie myli ludzi: Menedżer Aktualizacji może pokazywać 23 aktualizacje, podczas gdy linia komend mówi o 79 pakietach. To nie są różne zestawy aktualizacji; to ten sam system liczony inaczej.

GUI grupuje pokrewne pakiety w logiczne jednostki. Jedna "aktualizacja Firefox" w Menedżerze Aktualizacji może faktycznie składać się z binarnych plików Firefox, pakietu lokalizacji, współdzielonych bibliotek, od których zależy, i pakietu konfiguracyjnego, każde śledzone jako oddzielny pakiet przez apt. Więc to, co Menedżer Aktualizacji prezentuje jako jedną aktualizację, apt przedstawia jako cztery lub pięć indywidualnych aktualizacji pakietów.

Gdy to zrozumiesz, różnica przestaje być tajemnicza. Ktoś może powiedzieć "Miałem 100 pakietów do aktualizacji" dla tego samego zestawu zmian, które Twój Menedżer Aktualizacji pokazuje jako 30 aktualizacji.

Flatpak: Oddzielny menedżer pakietów

[5:56 - 6:41] Jest jedno, co łatwo przeoczyć: Linux może mieć zainstalowane wiele menedżerów pakietów, a apt zna tylko pakiety, które zarządza. Flatpak to jedna z takich alternatyw; to system oparty na izolowaniu, który pakietuje aplikacje z ich własnymi zależnościami, izolując je od reszty systemu.

Jeśli zainstalowałeś oprogramowanie przez Flatpak, uruchomienie apt upgrade nie dotknie tych aplikacji. Musisz je aktualizować osobno:

flatpak list
flatpak update

flatpak list
flatpak update

Polecenie flatpak list pokazuje wszystko zainstalowane przez Flatpak, a flatpak update aktualizuje te pakiety do najnowszych wersji. Warto regularnie sprawdzać, zwłaszcza jeśli zainstalowałeś IDE, narzędzia bazodanowe lub aplikacje komunikacyjne przez niego.

Na Linuxie oprogramowanie może pochodzić przez apt, Flatpak, Snap, a nawet ręczne instalacje. Każdy ma własny mechanizm aktualizacji, więc pełna rutyna aktualizacji powinna uwzględniać je wszystkie. Jeśli jesteś przyzwyczajony do tego, że każda aplikacja ma własny aktualizator, kluczową różnicą tutaj jest to, że musisz wiedzieć, który menedżer pakietów odpowiada za którą część oprogramowania, i uruchamiać odpowiednie polecenie aktualizacji dla każdego.

Jaką metodę powinieneś wybrać?

[4:19 - 5:32] Zdanie Tima jest takie, że oba podejścia są ważne, a właściwy wybór zależy od Twojego przepływu pracy. Jeśli czujesz się bardziej komfortowo z interfejsem wizualnym, Menedżer Aktualizacji obsługuje te same aktualizacje, które apt robi przez interfejs "wskaż i kliknij". Nie musisz zapamiętywać poleceń ani martwić się o wykonanie kroków w niewłaściwej kolejności. To powiedziawszy, istnieje dobry powód, aby zaznajomić się z linią komend: automatyzacja. Możesz stworzyć prosty skrypt powłoki, który uruchamia pełną sekwencję aktualizacji i zaplanować jego wykonywanie co tydzień za pomocą cron. Trzylinijkowy skrypt, który utrzymuje Twój system aktualnym bez potrzeby myślenia o tym, to rodzaj małej inwestycji, która się opłaca z czasem.

Poza automatyzacją, linia komend pozwala Ci selektywnie zastosować określone poziomy aktualizacji w zależności od kontekstu lub przekazać dane wyjściowe do innych narzędzi do analizy. Te opcje nie są dostępne przez GUI.

Audyt zainstalowanych pakietów

[7:16 - 7:54] Jest także użyteczny efekt uboczny procesu aktualizacji: przeglądanie listy aktualizacji działa podwójnie jako audyt tego, co jest zainstalowane na Twoim systemie. Kiedy widzisz pakiet w kolejce aktualizacji, warto zadać sobie pytanie, czy nadal go potrzebujesz.

Możesz zobaczyć Firefox na liście aktualizacji, gdy głównie używasz Edge, lub odwrotnie. Posiadanie dwóch zainstalowanych przeglądarek w celu testowania aplikacji webowych na różnych przeglądarkach ma sens, ale ogólną zasadą jest to, że lista aktualizacji ujawnia pełny zasięg Twojego środowiska programistycznego. Przestarzałe narzędzia z poprzedniego projektu, biblioteki deweloperskie, które zostały pobrane jako zależności i nigdy nie zostały oczyszczone, pakiety, które zapomniałeś, że zainstalowałeś sześć miesięcy temu: wszystkie pojawiają się tutaj.

Takiego rodzaju porządkowanie przynosi więcej korzyści, niż byś oczekiwał. Czyste środowisko programistyczne jest łatwiejsze do odtworzenia wśród członków zespołu, prostsze do konteneryzacji, i mniej skłonne do produkcji "działa na moim komputerze" błędów. Jeśli Twój komputer z Linuxem ma zainstalowane pakiety, których Twój Dockerfile nie obejmuje, możesz polegać na czymś, co nie będzie istniało w produkcji. Zaznajomienie się z wdrażaniem aplikacji C# do Docker sprawia, że to połączenie między lokalnymi pakietami a środowiskiem produkcyjnym staje się bardziej konkretne.

Wnioski

[7:54 - 8:25] Jak pokazuje Tim, cały proces — czy to przez Menedżera Aktualizacji, czy przez linię komend — zajmuje kilka minut co najwyżej i chroni przed kumulowaniem technicznego długu na poziomie OS. Uczynienie z tego cotygodniowego nawyku, a nie okazjonalnego obowiązku, utrzymuje Twoje narzędzia programistyczne, zależności runtime i biblioteki systemówe w zgodzie, a ta zgodność to to, co sprawia, że rozwój krzyżowy C# na platformy jest niezawodny zamiast frustrujący.

Aby uzyskać pełny przewodnik krok po kroku, zapoznaj się z filmem Tima Coreya na jego kanale YouTube.