TL; DR hoặc "Chỉ cần thiêu đốt pi của tôi"
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
(Lặp lại apt-get autoremove --purgecho đến khi không còn trẻ mồ côi)
Giải thích thêm
Nếu một gói foo phụ thuộc vào gói libfoo khác và bạn loại bỏ gói libfoo , thì phụ thuộc ( foo ) cũng bị xóa. Bởi vì Foo có một dòng phụ thuộc chỉ định libfoo , nó sẽ bị phá vỡ để rời khỏi foo nếu libfoo bị xóa. Điều ngược lại là không đúng: xóa foo không tự động xóa libfoo . Một gói xfoo thể cũng phụ thuộc vào libfoo, vì vậy apt sẽ không chỉ loại bỏ nó (mặc dù apt sẽ theo dõi nếu nó đã được cài đặt chỉ là một tác dụng phụ của việc cài đặt foo và đề nghị tự động xóa nó nếu bạn yêu cầu, miễn là không còn ai khác phụ thuộc vào nó)
Các gói meta phụ thuộc vào một tập hợp các gói khác theo cách tương tự như foo phụ thuộc vào libfoo , vì vậy khi bạn xóa gói meta, thông thường sẽ bị loại bỏ. Ví dụ: có thể có hai gói meta phụ thuộc vào xterm (có thể là lxsession và xfsession), nhưng gỡ cài đặt một hoặc cả hai sẽ không gỡ cài đặt xterm vì xterm không bị hỏng nếu không có lxsession hoặc xfsession. Các gói meta thường nằm ở đầu cây phụ thuộc, không phải ở dưới cùng và một vài thứ có xu hướng phụ thuộc trực tiếp vào các gói meta. Các gói meta chủ yếu cung cấp một cách thuận tiện để cài đặt một bộ gói hợp lý cùng một lúc, nhưng chúng không gỡ bỏ các công cụ.
Vì vậy, nếu bạn muốn ghi lại mọi thứ phụ thuộc vào X11, bạn sẽ cần nhắm mục tiêu vào bộ thư viện libx11 cơ bản mà tất cả các ứng dụng x11 cuối cùng phải phụ thuộc vào:
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
Điều này sẽ (mô phỏng) loại bỏ mọi thứ cuối cùng phụ thuộc vào libx11 -. *, Và cũng sẽ xóa bất kỳ gói nào được cài đặt dưới dạng phụ thuộc của chương trình X11 ngay cả khi chúng không phụ thuộc trực tiếp vào chính X11 (CUPS và Ghostscript thường được cài đặt như một tác dụng phụ của việc cài đặt một môi trường máy tính để bàn). Lệnh thứ hai sẽ loại bỏ những đứa trẻ mồ côi tiếp theo cho đến khi không còn lại. Xóa "--auto-remove" nếu bạn muốn thực hiện bước này sau hoặc hoàn toàn không thực hiện hoặc chỉ thêm lại các gói theo cách thủ công sau khi tắt GUI.
Xóa tùy chọn --dry-run để thực sự thực hiện thao tác sau khi bạn đã kiểm tra xem nó sẽ không xóa các gói bạn không có ý định xóa.)
Tôi thích làm sạch và thanh lọc các tác dụng phụ, và thêm chúng trở lại khi cần thiết. Ngoài ra, tôi đã đi trước và thử nghiệm điều này trên pi của riêng tôi, và nó đã khởi động lại vào một máy chủ rất spartan nhưng chức năng. :)
Tại sao một gỡ bỏ cài đặt một cái gì đó?
Chiến lược trên giải quyết vấn đề đã nêu, nhưng vẫn có sự tò mò về lý do tại sao một thao tác loại bỏ dẫn đến các gói được cài đặt .
Trọng tâm của mỗi người quản lý gói là một người giải quyết thỏa đáng của một số loại. Khi bạn yêu cầu người quản lý gói cài đặt một số gói, xóa một số gói hoặc nâng cấp một số gói, điều bạn thực sự yêu cầu là giải quyết tình trạng cài đặt phần mềm mong muốn tiếp theo với một bộ gói có sẵn. Giải pháp này có thể bao gồm cài đặt các gói bổ sung (phụ thuộc), loại bỏ các gói hiện có (xung đột, phá vỡ), hạ cấp / nâng cấp các gói cụ thể (mức độ tương thích) hoặc kết hợp chúng. Vì vậy, mặc dù hơi phản cảm khi người giải quyết xác định rằng một số gói cần được cài đặt để các gói khác bị xóa, nó làm cho ý nghĩa hoàn hảo. Đây là vấn đề quản lý phụ thuộc khó chịu mà các nhà quản lý gói giải quyết.
Một ví dụ cụ thể: Cho một tập hợp các ứng dụng Java đã được cài đặt, tất cả chúng đều phụ thuộc vào thời gian chạy tương thích java mà hiện đang xảy ra là openjdk-7-jre . Sau đó bạn có yêu cầu quản lý gói để giải quyết cho việc cài đặt của một công cụ Java mới mà tuyên bố một cuộc xung đột với openjdk-7-jre nhưng làm việc với oracle-7-jre (cả gói quát cung cấp một java-7-runtime ). Bộ giải sẽ đề xuất một loại bỏ của openjdk-7-jre và cài đặt của oracle-java-7-jrelà giải pháp cho trạng thái mong muốn của bạn khi cài đặt gói mới trong khi không phá vỡ các gói hiện có.
Trong trường hợp cụ thể này, xterm là gói cung cấp một phụ thuộc ảo được gọi là x-terminal-giả lập ( xterm , lxterminal và aterm đều cung cấp một trình giả lập x-terminal ), do đó có khả năng loại bỏ lxterminal (như một phần của loại bỏ lxde), bộ giải tìm thấy một gói đã cài đặt hiện có ( chuyển mã như một ví dụ có thể) yêu cầu một số loại trình giả lập x-terminal , vì vậy bộ giải đã chọn cài đặt xterm (yêu cầu libutempter0 và xbitmaps, giải thích các gói khác để cài đặt) để đáp ứng sự phụ thuộc bị hỏng. Nếu không thấy cơ sở dữ liệu gói, tôi sẽ đưa ra giả thuyết rằng đây là tình huống có thể xảy ra nhất.
Để khám phá các gói hiện đang phụ thuộc vào xterm (hoặc thay thế), sử dụng apt-cache rdepends lệnh (sử dụng --installed tắc để hạn chế các gói cài đặt duy nhất):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Các phụ thuộc bắt đầu bằng ký tự xen kẽ '|' có nghĩa là gói phụ thuộc vào xterm hoặc thứ gì đó mà nó cung cấp (cái gì đó là trình giả lập x-terminal trong trường hợp này). Các clusterssh gói phụ thuộc vào xterm một cách rõ ràng , và không cho phép một sự thay thế. Đây là danh sách ngắn của các gói gây xterm được yêu cầu.
Điều gì về deborphan?
Chức năng theo dõi trẻ mồ côi đã được tích hợp vào apt-get thông qua chức năng 'autoremove' trong năm 2010 (lỗi Debian 582791 ) khiến cho trình biến hình chủ yếu là dư thừa và về cơ bản là lỗi thời. Không giống như deborphan và các giải pháp khác giống như vậy, apt-get trực tiếp theo dõi các gói nào được cài đặt rõ ràng và gói nào được cài đặt dưới dạng tác dụng phụ hoặc phụ thuộc của gói được cài đặt rõ ràng. Ví dụ, nếu một quản trị viên cài đặt foo, libfoo được cài đặt như là một tác dụng phụ và apt-get autoremove ý chí , trên thực tế, loại bỏ libfoo nếu autoremove (hoặc --auto-remove) được xác định khi loại bỏ foo.
Cách tiếp cận được thực hiện bởi deborphan là một tập hợp các phỏng đoán. Ví dụ: đoán rằng một thư viện đã cài đặt không có người phụ thuộc phải là trẻ mồ côi: Nếu libfoo được cài đặt, nhưng cả foo và xfoo đều không, deborphan có thể quyết định nó phải là trẻ mồ côi. Một chế độ thất bại ở đây là các thư viện có thể được cài đặt riêng cho các công cụ mà họ cung cấp (libxml2 cho xmllint trước khi được đóng gói lại thành libxml2-utils) hoặc đơn giản là có sẵn cho mục đích phát triển. Những gói như vậy không phải là trẻ mồ côi. Ngoài ra, deborphan tập trung vào các thư viện, do đó, nó bỏ lỡ một số trẻ mồ côi không phải là thư viện mà apt theo dõi (các gói lỗi thời so với các gói mồ côi) .
muninvì một số lý do, nhưng tôi có thể đưa nó trở lại đủ dễ dàng sau đó.